The Advanced Database Guide: Beyond Plain PostgreSQL

My Accidental Database Degree: The Over-Engineered Journey Behind a Simple URL Shortener

In 2023, I started working on a project called Clickly. It’s a URL shortener, similar to Bitly or Short.io. You click a short link, it redirects you to the original, and in between we do the tracking. Simple enough, right?

I saw companies like Bitly making good money, and I’ve been a little passionate about this space. I thought, let’s build it. But I’m an engineer, and even though the mantra was “do things fast rather than over-engineer,” I’m going to over-engineer. That’s probably why I wasn’t successful with that particular product. But over-engineering, man, it helps you learn so many things. This is the story of that learning.

Phase 1: The Obvious Choice – PostgreSQL

We started with the most basic requirement: a PostgreSQL database. For storing link mappings, user logins, sign-ups, authentication, OTP, user preferences—Postgres is more than enough. We used Neon for our Postgres instance, and it worked like a charm. Everything was clean and simple. (Every schema change after that first table is a migration — the versioned kind you run on deploy — and I wrote up how database migrations actually work, including how not to lose data at 2 AM.) (Clickly’s database was one of seven I keep on Neon’s free tier to this day — here’s how I run all of them for $0.) (If you’re still deciding where to run that Postgres — Neon, Supabase, or the ghost of Vercel Postgres — I compared the cheap serverless options in this post before going down the rabbit hole below.)

But then my internal engineer brain woke up with an entrepreneurial anxiety attack: how do I give the absolute cheapest price to an individual user? That question sent me down a rabbit hole.

To be cheap, I needed to store analytics events (every single click) and let users fetch them fast without me paying a fortune. If TinyURL was built 15 years ago, how could I make something today and still be profitable? The answer, I thought, was in specialized databases.

Phase 2: The Analytics Engine Hunt

OpenSearch on DigitalOcean

I knew I hated AWS. I didn’t want to go anywhere near it. So I started exploring OpenSearch, the open-source fork of Elasticsearch, offered by DigitalOcean. For about $19 a month, you can store click event data and read it incredibly fast. These analytics databases are fantastic for reads. But they’re not great for heavy writes, so you often need a cron job or a buffer to slowly push data in. (The enterprise end of this world is a Spark lakehouse like Databricks — I decoded its two-layer pricing and why a founder almost never needs it.)

That limitation made me look further.

ClickHouse – Enterprise Grade, Startup Killer

I came across ClickHouse. It’s an enterprise-grade open-source analytics database, blazing fast. The problem? The entry tier alone runs around $66 a month, and real production pricing climbs fast from there. That might be fine if you have customers, but I was a broken entrepreneur. I didn’t want to pay that plus taxes. ClickHouse has one flaw similar to others: write speed can be a bottleneck if you’re not careful. Still, it’s a great option to keep in mind for heavy analytics use cases. (It’s also where fleeing Datadog customers land: when one company’s observability bill hit $65M/year, they rebuilt on Grafana, Prometheus, and ClickHouse — the whole story is in the Datadog monitoring guide.) (Funny enough, ClickHouse is exactly what PostHog runs on under the hood — which is the whole reason you should let them host your analytics instead of you; more on that in the $0 analytics stack.)

Timescale – PG Strikes Back

I wanted back into the Postgres ecosystem. I was drifting too far and spending too much imaginary money. Then I discovered Timescale. It’s an open-source extension for PostgreSQL. With Timescale, you can have regular Postgres tables for your standard data, and hypertables (compressed, columnar-like storage) for time-series analytics—all inside a single database.

I started exploring Tiger Cloud, the managed service from the New York company behind TimescaleDB (they rebranded to TigerData in 2025). For about $30 a month, you get a database that is very high speed. You can even run everything on Tiger Cloud without needing a separate Neon instance. The killer feature: normal tables for user data, Timescale hypertables for analytics events. Compression keeps costs low. It felt like the perfect middle ground.

Phase 3: Getting Even Cheaper with Files

Parquet Files + DuckDB

I wanted to see how far I could push the “cheap” idea. I landed on Parquet files. Parquet is a columnar storage format. Even with millions of rows (remember, I have zero users but I’m ambitious), the compression is so good that it takes up only a few MBs. You can store one Parquet file per user, drop them into any S3-compatible storage—like Bunny Storage or DigitalOcean Spaces—and query them directly using DuckDB without downloading the entire file every time.

No separate database server, per-user isolation, GDPR-friendly from the start, and ridiculously cost-effective. This was one of the most awesome things I learned.

Per-User Databases: Turso

Thinking about per-user isolation led me to another question: what if each user got their own entire SQLite database? That’s exactly what Turso does. They forked SQLite and built a platform where you get isolated databases per user or per project. This is huge for use cases like AI agents or multi-tenant apps where you want strong boundaries. Lots of AI coding companies are using Turso for this exact reason. If you need per-user database storage, check them out.

Phase 4: The MySQL Fork in the Road – PlanetScale

I also explored the MySQL side of things. I learned about Vitess, an open-source project created to scale YouTube’s MySQL databases horizontally. The people behind Vitess left YouTube and started PlanetScale. PlanetScale isn’t cheap—they dropped their free tier a while back—but their customer list is insane, packed with serious, high-scale companies. The dashboard feels as intuitive as Neon’s; you get read replicas, bare-metal performance, and no cold starts. If MySQL is your jam, PlanetScale is worth a serious look. (Torn between the two engines in the first place? I settled it in PostgreSQL vs MySQL — Postgres for ~99% of SaaS, and exactly when MySQL earns the exception. And if you’re eyeing the NoSQL side, MongoDB Atlas pricing shows why the managed-document route gets expensive fast.)

Notable Mentions from My Obsession

• Bunny: They started offering a Postgres service, and I was a beta user. It turns out they use Turso’s SQLite tech under the hood—on-demand storage where the database file sits in an S3 bucket and loads into an instance only when needed. It’s clever, but very early. I’d only use it for hobby projects right now, not production. (I wrote a whole love letter to the rest of their platform in the Bunny story.)
• Northflank: This is more of an AWS/GCP/Azure-friendly platform with a nice moonlit UI. It’s great if you like that cloud ecosystem vibe. They have a database offering too, but it feels like their main focus is the full developer platform.
• Koyeb: They have a PostgreSQL database, but it’s pretty basic compared to Neon or PlanetScale. Their main thing is AI-heavy, large EC2-like instances. Point-in-time recovery, automated backups—the features just aren’t as mature for the price. If Postgres is your core, Coab isn’t the star.

The Aftermath

I experimented with all of this. I never launched Clickly the way I dreamed, but I collected a database curriculum no course could teach. Postgres remains the heart, Neon the easy start. (If you just want the no-drama starting point without the rabbit hole, that’s the broke solopreneur’s survival guide.) For analytics on a budget, Parquet + DuckDB or Timescale are gems. For per-user isolation, Turso changes the game. And if you need MySQL scale, PlanetScale is beautiful.

The database was only one of the rabbit holes Clickly sent me down, by the way. I also asked myself whether I needed a real event-streaming pipeline (spoiler: no, and here’s what a Kafka topic even is) and whether I should orchestrate the whole thing on a cluster (an even more expensive mistake I actually made). Same disease, different tool.

I’ll keep adding to this list as I discover new databases. If you’re on a similar journey—chasing the cheap, the fast, the over-engineered truth—subscribe and follow along. We’re going to explore every single one, one database at a time.