Paul Copplestone Bet on a 40-Year-Old Database - Then AI Came Knocking

The first useful fact about Paul Copplestone is that his great database adventure began with annoyance. At Nimbus for Work, the office-management startup where he was co-founder and CTO, a chat product built on Firebase would not scale the way he needed. So he moved the data to PostgreSQL. Then he rebuilt the real-time behavior he missed, released the work as open source, and watched developers appear.

It was less a lightning bolt than a bug report from his own life. Copplestone had wanted to build developer tools for years, specifically a database company. Two startups came first. The third finally matched the private ambition. “I think this is the one that I wanted to do all along,” he said in a 2025 conversation about Supabase.

The result was an unusually legible promise: take the convenience developers liked about Firebase, put it on top of Postgres, and publish the machinery. Supabase would offer a database, authentication, storage, instant APIs, real-time subscriptions, and serverless functions. Yet the data would remain in a mature relational system with an enormous ecosystem. Convenience arrived without requiring a lifelong lease.

The scenic route to Postgres

Copplestone grew up in New Zealand and learned to build products before he learned the startup dialect. He has recalled knowing little about venture capital or the usual acronyms. His entry into startups came through a plot twist that would be rejected from a tidy founder biography for seeming too convenient.

He had signed a contract to work for the Australian government. When he arrived, he was told that, as a New Zealander, his hiring required a case showing that an Australian could not do the job. He was sent away for a week. During that pause, a friend was speaking with someone preparing a startup in Malaysia. Why not come help? The skyline sounded more appealing than the paperwork. Copplestone went.

That startup became ServisHero, a marketplace connecting people with local service providers. Its origin was gloriously unglamorous. The early team worked from a coffee shop in Kuala Lumpur’s Pavilion mall because their apartment had no Wi-Fi. When early developers dropped out, Copplestone built the first product himself. Within roughly 18 months, the company had grown from a few people around a café table to more than 75 employees. Code had acquired payroll, operations, sales, and all the other things code pretends not to need.

Singapore supplied the next hinge. At Entrepreneur First, Copplestone joined a room of would-be founders expected to find one another and form companies at speed. He met British engineer Ant Wilson. They did not start a company together there. They did live together afterward in a hacker house with roughly seven people attempting six companies, a domestic arrangement that sounds like an excellent way to test both bandwidth and temperament.

When Copplestone was ready to pursue the database idea, he called Wilson. The pitch included building a developer-tools company and, after Wilson’s repeated applications, finally getting into Y Combinator. They formed Supabase in January 2020 and entered YC’s Summer 2020 batch. A company designed for remote developers was born just before the world made remote work compulsory.

A public product needs a public clock

The early break came after the company changed its description to “the open source Firebase alternative.” A Cloudflare engineer placed it on Hacker News. The post rose to the front page, the project attracted attention, and developers responded with an unambiguous request: build authentication. During YC, the tiny team did exactly that.

After Demo Day, the fixed target disappeared. Copplestone and Wilson recreated it. Launch Weeks became artificial deadlines with real output: choose a date, finish as much as possible, release publicly, and let the community answer. The ritual provided a spine for a company with a flat structure and people scattered across time zones.

Copplestone describes the organization as closer to an open-source community than a conventional hierarchy. Teams listen to developers and priority customers, announce what they intend to do, and work toward shared launches. He favors people who are curious, hardworking, intellectually honest, and comfortable with autonomy. Former founders fit because they can take possession of an entire problem without requesting a daily itinerary.

The alignment is almost suspiciously neat. Supabase gives developers agency over infrastructure; Supabase gives its own builders agency over work. The trade is that judgment matters. A flat company cannot outsource every difficult choice to the rectangle above it on an organization chart.

There is wit in the presentation, too. Supabase became known for memes and playful launches. Copplestone gives much of that credit to Wilson, the CTO and, in boardroom folklore, “meme lord.” The humor was not a brand strategy delivered on tablets. It worked, so the team repeated it. This is Copplestone’s kaizen instinct in miniature: keep the pieces that help, discard those that do not, make the next pass slightly better.

The old database meets the new builder

Postgres is the sober character in this story. It is older than many people using Supabase, deeply documented, widely understood, extensible, and happily untroubled by fashion. Copplestone’s wager was that the fashionable layer should sit above the durable one. A startup could improve onboarding and APIs without inventing a proprietary data model that customers might one day have to escape.

That technical conservatism became unexpectedly useful when AI coding agents began assembling applications. Agents prefer products they can understand through documentation, public examples, consistent APIs, and abundant community discussion. Supabase had spent years making itself easy for humans to learn in public. Machines inherited the reading list.

By June 2026, Supabase said database launches had grown 600 percent in a year. More than 60 percent of new databases were being launched by some kind of AI tool, and nearly 10 million developers were using the platform. The company had crossed 100,000 GitHub stars two months earlier.

The growth altered the scale of the engineering problem without changing its center. Supabase’s June 2026 Series F brought in $500 million at a $10 billion pre-money valuation. Copplestone assigned the money to three plain purposes: accelerate open-source and Postgres development, support growth, and provide employee liquidity.

On the same day, the company released an alpha of Multigres, an open-source effort aimed at high availability and horizontal scaling for Postgres. Work on OrioleDB continued toward a modern cloud-native storage engine. These are not decorative features for a landing page. They address the awkward, expensive parts of operating databases at scale: bloat, pooling, failover, and sharding.

The discipline of leaving money alone

Scale also brings customers carrying long requirement lists and very large contracts. Copplestone has spoken about declining million-dollar enterprise deals when their demands would pull the roadmap away from the product. He admits that the choice feels painful. Good principles often arrive wearing the expression of a finance director who has just seen the number.

The refusal protects a feedback loop. Enterprise developers are valuable when they behave like builders and help steer the platform through real friction. They are less useful when a contract converts a general product into private consulting. Supabase wants large organizations, but it wants them through the same front door.

This position is easier to state after a large funding round, yet Copplestone’s public record suggests it predates the comfort. The company’s early enterprise offering moved useful protections into lower-priced plans, including spend caps designed to prevent ugly billing surprises. Portability, transparent pricing, and open code all serve the same customer emotion: the relief of knowing where the exits are.

Copplestone is equally careful about retrospective genius. He talks openly about timing and luck. Supabase had a capable team and a product that fit the moment, he says, but someone else might have captured the opportunity. The tone is not false modesty so much as systems thinking applied to biography. Inputs matter; chance is one of them.

A very long process

His personal website remains wonderfully spare. It calls him a full-stack developer and entrepreneur, labels part of itself a “personal dumping ground,” and lists small projects alongside three companies. There is a cleaner interface for PostgreSQL mailing lists, a collection of mental models, and a current-events newsletter. He also publishes a long list of investments in open-source and developer-tool companies. The portfolio reads like a map of his interests: composable software, practical interfaces, and tools for people who make things.

Asked about startup challenges, Copplestone once observed that people look at a snapshot and forget the length of the process. He hopes Supabase can persist for generations. That aspiration places the funding headlines in their proper, slightly comic scale. A valuation is a photograph. A database is an obligation.

The useful lesson in his route from New Zealand to Malaysia, Singapore, and Supabase is not to copy the itinerary. It is to notice how often he followed friction toward a more interesting problem. A stalled contract produced a startup. A missing apartment connection produced a coffee-shop office. A Firebase constraint produced an open-source experiment. The absence of Demo Day produced Launch Week.

Copplestone’s career keeps converting inconvenience into architecture. The work now is to ensure that nearly ten million developers, and an expanding population of tireless coding agents, can continue to build without discovering that ease has quietly become captivity. Postgres provides the memory. Open source provides the exit. Supabase provides the polished yellow door.