Announcing Our $2.5M Pre-seed Funding to Enhance PostgreSQL Scalability

We’re excited to share that we’ve raised $2.5 million in pre-seed funding to make scaling Postgres simpler and more efficient. The round was led by Gradient, with participation from Octave and angel investors.

PostgreSQL is a remarkable database. It’s open-source, battle-tested, and feature-rich, making it an easy choice for everything from MVPs to multi-tenant production systems.

But as your workload grows, it can get harder to keep up. Queries slow down, the primary gets overloaded, and background jobs start competing for the same resources.

You can throw more compute at the problem. You can add read replicas or write custom infrastructure to split the load. You can even look at migrating to a new database entirely. But all of that takes time, money, and engineering effort—often pulling focus away from your actual product.

We’ve lived that pain firsthand.

At our last company, we ran into the same issues. Read replicas had the potential to improve performance on the primary, but we didn’t have the bandwidth to refactor our application logic to separate reads and writes across different endpoints.

Instead, we did what we could: sharding, bigger instances, caching layers, ETL jobs. It helped, but we still spent too much time and money managing database infrastructure, which took away from building the features our users wanted.

That’s why we started Springtail.

Introducing Springtail, a new way to scale Postgres

At its core, Springtail is a distributed database that separates storage from compute, providing seamless horizontal scaling for read-heavy workloads. This means you can increase query throughput by simply adding more compute nodes, making your application faster and more responsive under load without overpaying for capacity you don’t always use.

What makes Springtail different is that it works with the Postgres instances you already have.

Our service sits between your app and Postgres, offloading read queries and taking pressure off your primary. Springtail connects to your database’s logical replication stream to create a real-time, scalable replica of your dataset.

Your existing Postgres instance remains the source of truth. No migrations. No application changes.

Better replica performance, at a lower cost

While our vision for Springtail is broad, we’re starting with a focused use case: scaling Postgres read replicas for Amazon RDS more efficiently and cost-effectively.

Traditional replicas force you to pay for full capacity, even during periods of low usage. With Springtail, you can scale compute up or down based on demand, helping teams cut read replica costs by as much as 58% compared to RDS.

Springtail is a great fit for:

• Recurring jobs like nightly analytics or batch processing.
• Read-heavy datasets like dashboards, catalogs, or user profiles.
• General read scaling for applications under heavy traffic.

If you’re hitting read limits or just tired of paying for underutilized replicas, Springtail can help.

Even if you’re not running into scaling issues yet, Springtail helps you stay ahead. It future-proofs your existing Postgres so you won’t need a big re-architecture later. And in the meantime, you can still save money by right-sizing replica capacity to match your actual usage.

Thank you to our investors

We couldn’t have reached this milestone without the support of our incredible partners.

We are thrilled to be part of the Gradient family and grateful to Zach Bratun-Glennon and Vig Sachidananda for their ongoing guidance and support. We also want to thank William Smith at Octave and our angel investors for believing in us early on.

Let’s chat

If you’re wrestling with Postgres performance, want to save money on your read replicas, or are just curious about Springtail—reach out!

We’re actively working with design partners and would love to hear from you.

Check out our docs and request access to get started.