“We were getting ready to hire dedicated engineers just to manage and scale Zite Database. With Neon, we didn’t need to do that – we were able to give every end user their own database (including on the free plan)”

(Dominic Whyte, Co-founder at Zite)

Zite is an AI-native app builder for the kind of internal and external tools that simplify daily tasks for business teams, from dashboards to CRMs to AI apps. It is built by the team behind Fillout, a product used by tens of thousands of teams every week to collect and work with data.

The core principle behind Zite is to help teams turn ideas into truly operational software. Apps come with a built-in backend database, workflows for business logic, and user management with permissions handled out of the box; non-technical subject-matter experts can describe what they want to build, and the platform takes care of the infrastructure needed to run it reliably.

They also have a handy marketplace with templates you can explore for inspiration.

Operational business apps need a real Postgres database

Even before Zite launched, the original Fillout team was already aware of the need for adding a database as a first-class product in the stack.  Fillout users were already collecting structured information every day, e.g. responses flowing into tables, powering workflows, and feeding downstream tools; and as teams started building more complex applications, the limits of relying on a hidden storage layer became obvious. 

With the launch of Zite, those needs became even more pronounced. Zite users weren’t just collecting data: they were now building full business applications, and those apps needed a database underneath it.

So the team decided it was time to make the database itself a first-class part of the product. They built Zite Database, a managed database tightly integrated within Zite’s forms and app builder. Users could now create tables, work with millions of rows, and use the database as the foundation for dashboards and custom applications – all without having to set any infrastructure up themselves or worry about scaling.

A shared storage layer breaks at scale

“We first considered running Zite Database on a large, shared Postgres database in RDS, but it quickly became clear that this wasn’t an ideal long-term solution”

(Dominic Whyte, Co-founder at Zite)

The initial architecture for Zite Database initially involved a single large Postgres database hosted on AWS RDS, with customer data logically sharded across organizations. But the limits of a shared database became increasingly apparent, especially as adoption took off: 

• Noisy neighbors became inevitable. Some Zite customers were building lightweight apps, while others were sending thousands of requests per second. 
• Performance was hard to optimize. A single database had to serve wildly different usage patterns, making performance tuning difficult. 
• Isolation was complex.  While data was separated logically, performance and reliability guarantees were still shared.
• Scaling = operational work. Growing usage required constant monitoring, tuning, and capacity planning.

Rethinking the architecture: deploying databases-per-customer via Neon 

The team began to rethink the architecture from first principles. Instead of asking how to safely pack more customers into the same database, they flipped the question: what if every customer had their own isolated database? 

On paper, that sounds expensive and operationally heavy – but this is where Neon enters the picture.

Neon is a serverless Postgres database with a unique shape that makes it particularly well suited for powering in-app and embedded database products, like Zite Database. Rather than treating databases as heavy, monolithic infrastructure, Neon makes them lightweight and programmable, allowing APIs to spin them up and manage them automatically. 

• Instant provisioning. Neon databases can be created in seconds, making it possible to give every organization a dedicated Postgres database the moment they create their first one.
• API-first. Platforms like Zite can treat the database as part of the product flow rather than a manually operated service.
• Usage-based pricing. Costs scale with real usage instead of pre-allocated capacity, making it economically viable to deploy many isolated databases. 
• Scale-to-zero Databases that aren’t actively used don’t consume compute, which is critical when running a large fleet with a free plan. 

Neon’s model allowed Zite to fully embrace a per-customer database architecture without introducing additional operational burden – in fact, it reduced it. They simply integrated Neon into their platform: Zite uses Neon’s TypeScript API client to provision and manage databases directly from their application code. They didn’t have to build custom abstractions or infrastructure tooling.

“Because Neon is usage-based and can scale down databases when they aren’t being used, we’re able to deploy thousands of new databases per day without costs getting out of hand”

(Dominic Whyte, Co-founder at Zite)

Building products on databases, not around them

By rethinking its database architecture, Zite turned what could have been an operational bottleneck into a core product advantage. Deploying and managing Zite Databases stopped being something the team had to worry about and they could fully focus on providing a great end-user experience.

Get a first-hand taste of how it looks by creating a free Zite account and building your first apps running on Zite Database.