Most SaaS products don’t need a data lake in their first years. One well-run Postgres database, with a product analytics tool beside it, covers the app and most of the reports a young company needs. A data lake starts to pay for itself when you keep large amounts of raw events or files, when analysts need years of history, or when heavy queries slow the app down. This guide shows the signs, what to run at each stage, the 2026 prices to plug into your own math, and how to plan deletion before you collect anything.
The three names get mixed up, so here is the plain version.
| Database | Data warehouse | Data lake | |
|---|---|---|---|
| Holds | Live app data: users, accounts, orders | Cleaned, structured data for reports | Raw data of any shape: events, logs, files, exports |
| Used by | The app itself | Analysts and dashboards | Analysts, data scientists, machine learning jobs |
| Typical question | “Show this customer’s invoices” | “Revenue by plan by month” | “Every click from every account for three years” |
| What you pay for | Server size | Storage plus queries | Cheap storage plus the data each query scans |
A lake isn’t a better database. It sits next to the database and keeps what the app doesn’t need to serve customers.
PostgreSQL 18, released on 25 September 2025, added an asynchronous I/O subsystem. The PostgreSQL project reports read speed-ups of up to 3× in certain scenarios, and a new uuidv7() function creates IDs ordered by time, which index better (PostgreSQL 18 release). With a read replica for reports, one database carries a SaaS a long way.
The first thing that usually outgrows the app database is the event stream: page views, clicks and logs that arrive far faster than business records such as accounts and invoices. On Subflare, a lead scoring product that records what visitors do on a client’s website, we kept app data in PostgreSQL and put the stream of visitor events in DynamoDB, with Redis and BullMQ for background jobs. The event stream stayed out of the app database, and the MVP needed no lake.
If two or more are true, start planning a lake. If only one is, a read replica or a warehouse is usually enough.
A lake has two main bills: storage and queries. Both are cheap per unit and easy to waste.
An illustrative month, using those list prices: 2,000 GB of stored events at $0.0265 per GB is $53. Queries that scan 1 TB a day for 30 days at $5 per TB come to $150. The scan bill is already about three times the storage bill, which is why the Athena example matters: file format and column choice decide your cost more than data size does. The people who build and run the pipelines usually cost more than both.
Raw events with user IDs in them make privacy requests harder. Under UK GDPR, the ICO says you must respond to an erasure request without undue delay and at the latest within one month. For backups it says “the key issue is to put the backup data ‘beyond use’”, even if it can’t be overwritten at once (ICO, right to erasure).
In practice: keep the link between a person and their ID in one place, store events under that ID rather than names or emails, and pick a table format that supports row deletes. Subflare had the basics from day one: clients and leads can delete their data, and all data is stored on AWS in Europe. This is planning advice, not legal advice.
Data work is easy to underprice because it hides behind one line like “add analytics”. Break it into stories a customer or an analyst would notice, such as “export one account’s events as CSV” or “show weekly active accounts by plan”.
You can get a free project estimate for it from a short brief. The estimate turns your brief into user stories, and you confirm what is in scope, so every hour in the budget traces back to a story you kept. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. You get an hours range, a budget range and a number of weeks, as a planning range rather than a fixed quote. If you’re still building the product itself, our SaaS development page lists our published price for a first release: $5,000-15,000, typically 2-4 weeks.
It is cheap storage for raw data of any shape, such as events, logs and files, kept next to the app database rather than inside it. Analysts and machine learning jobs read it; the app doesn’t serve customers from it.
When two or more of these are true: raw events grow much faster than app data, analysts need years of history, you train models on raw data, customers want exports of their full history, or several tools must read the same data. Before that, a read replica or a warehouse is usually enough.
Storage and queries are the two main bills. AWS lists S3 Tables at $0.0265 per GB a month for the first 50 TB in its US West (Oregon) example, and Athena at $5 per TB scanned. Compressed, column-based files such as Parquet cut the scan bill sharply; the engineering time usually costs more than both.
A warehouse holds cleaned, structured data for reports and dashboards. A lake holds raw data of any shape for later use. Many SaaS companies need a warehouse first. A lake comes later, or under the warehouse, once raw data becomes large and valuable.
Yes. On Subflare we built event capture, dashboards and an admin panel, with app data in PostgreSQL and visitor events in DynamoDB. We price this kind of work from user stories at $39-55 an hour.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.