Worries about massive writes to DB?

Ten measurements taken multiple times a day for a couple thousand companies is basically nothing for modern DB technology. Unless by multiple times a day you mean like every millisecond.

One thing to consider is whether you need historical data or not. If that isn't important, take a look at distributed streaming services like Kafka. They're built to scale to billions of events with no problems.

Pre-mature optimization kills startups before they get off the ground. You will discover your bottlenecks and usage as you build it. Iterate accordingly. If you worry about server costs right now, would you be able to sustain for weeks/months waiting to achieve traction?

Your worry should be to find product-market fit asap. Efficiency comes later on.

If you are using AWS and you don't need real time data you can publish the data to SQS and then read from the queue in a lambda and write to the db. You can set a concurrency limit of how many lambdas can run in parallel limiting the number of writes happening to the db at any point. SQS and lambda are fairly inexpensive to run and also give away a lot of free usage.

Because there are a lot of good technical answers here already, I want to add this:

People often underestimate what a database can take and overestimate the complexity of their problem.

Instead of worrying about an issue that you don't have yet, go and build it. If you get at a point where the database can't handle your throughput any more, you can still circle back and ask for specific programming approaches to make it work. Also at that point, StackOverflow will be likely a much better resource than IH.

Somehow the question seems to be pretty vague.

think tens of measurements taken multiple times a day for over a thousand companies.

how many times a day? 2, 3 , 100 ?
how many measurements? 10, 20 50?
how many thousand? 1000?

a quick math gives you a lower bound of 20k datapoints/day -- that is not much. Any modern db can handle more than X10 datapoints. Pricing really depends on your cloud provider, I would venture on self-hosting the db and just a managed storage volume (again, really depends on your budget, selfhosting = do your own maintenance!)

You can find many dbs that specialize on "tick data" that offers a good balance between data compression vs performance.

Start small, iterate as you go. Focus more on your architecture than technology

I've worked on systems that do 100K+ requests per second. Unfortunately, the answer to any question at that scale, or your scenario, really depends on the what you're trying to achieve... For your particular scenario, you didn't say what you're trying to do with the data. Do you need that accuracy or are you okay with less frequent updates?

What's the end goal?

What’s on your mind in terms of the database, programming language, software architecture?

For now, I have 2 things (not sure if you have already think about)

1. Find a suitable database.

Each database can have a different data format that affects its operation (read, insert, update, delete)

In general, insert and read data will be less expensive than the update. And your application seems to use insert and read the most.

If so, find one that optimizes for reading and insert. Hopefully, it is available

2. Cache or store query

Your app seems like a search engine. Try to cache or store query’s result somewhere, so it only gets data and calculates once

How long do you need to keep that data around? And do you actually need to write to a database? Are you going to have relationships between the data that requires a database?

It's kind of hard to solution for this without knowing what the data and schemas look like that you'll be storing, but you can look into data compression before storage, other options like S3 + Athena, etc.

For the reads, you can take some pressure off the database by implementing caching (check out Redis, for example). And if you are literally just fetching data (a la SELECT something FROM some_table), and don't have complex joins or queries, then the queries will be faster. There are of course other query optimizations you can do (like indexing your tables to help make the SELECT's faster if there is lots of data).

That being said, I wouldn't start out with caching (or worrying about queries too much) until you actually are noticing performance issues. You should avoid premature optimization.

You should probably do some calculation to figure out what you are really talking about in term of volume, most importantly written top burst per second, secondly total volume stored after a year and only thirdly the read/sec top.
What you described on top sounds like it might be too low to discuss, but if you consider different paths...
Try to think of it as flat files for simplicity, take the biggest "table" and do average char count, than how many rows and multiple.
That's your bytes, than /1024/1024 and we talk MB /1024 and we are in GB
Write, unless you are pass 20MB/sec, it's tiny, single disk cheap, not interesting, 100MB you might be needing bigger nodes but it's still not too much probably
on storage you can see AWS EBS per GB price for example, it's not too much...
The thing with reads is usually this is already usage, meaning you can already get income, so when read grow, your income grows, so you don't care much as it's direct costs... inc. read capacity is way easier than the other parts as there isn't a congested bottleneck usually and there are many layers you can cache info at....

on finance btw there are plenty of APIs you can probably do a no storage system that just calls other apis to resolve information without even storing anything if you wanted to..

What might be more interesting is if you want just stale data like yesterday or live up to the minute data (that's expensive to get), your data sources, what processing your going to do etc.
Finance/stock market data starts sounding simple and when you dig deep there are a lot of small details, like stocks that do splits or reverse splits, renames, dividends, exchange hiccups that backdate fixed and more.

Also there are nosql datastores for example that sacrifice stuff for gaining speed like less efficient storage and possibility of losing data but give you 10x-100x and high returns on higher bounds...

Also you can save money with non cloud hosting, getting VMs/HW might be cheaper than real cloud providers by 3x on some contexts...