|
|
|
|
|
|
by potamic
405 days ago
|
|
|
Compute is not the only bottleneck with running analytics on your transactional DB, there is also storage bandwidth and costs. Which is why once you cross a certain scale, you will want to separate out your analytics use case. I've always been tempted to do analytics over my transactional DB, but knowing that eventually I will need to move it out, felt it's just simpler to separate it out from the start. Since you're advocating for the opposite, who do you see as your potential customers? Specifically, where in the lifecycle their growth do you see Hydra fit? Is it more for early stage or medium scale companies that can benefit from getting started with analytics quickly or can it continue to cater (at reasonable cost!) as they cross terabyte/petabyte scale? |
|
|
Events, time-series data, user sessions, click, logs, IOT sensor readings, etc. generate a lot of data over time. While on-disk storage works well for Postgres’ rowstore, it’s a poor choice for fast growing data that requires analysis. To avoid the scale limit of on-disk storage, Hydra separates compute and storage. Also, we're not charging separately for bandwidth since it's been factored into the overall plan price.
While storage volume can be a good proxy, many people see the limits of Postgres with a complex join and filtering on relatively small data volumes. With decoupled columnstore and serverless processing, Hydra can be used in big (and small data) use-cases. Company size is a little less relevant since medium and large-scale companies have use-cases where efficient 'small data' is needed too.