Skip to main content
Most real applications need somewhere to store information. Customer accounts, leads, orders, bookings, projects, messages, subscriptions, settings, and other application data need to remain available after a user closes the browser or returns later. AIWA uses Neon Postgres to provide persistent database infrastructure for applications that need it. When your application requires stored data, AIWA can create and work with the database as part of building your product.
You describe the data your product needs. AIWA helps turn those requirements into a working database-backed application.

​
What is a database?

A database is where your application stores structured information. Imagine you’re building a CRM. Your application might need to remember:
  • Leads
  • Customers
  • Team members
  • Deals
  • Follow-ups
  • Notes
  • Activities
Without persistent storage, information entered into the application could disappear when the application reloads. A database allows your application to save that information and retrieve it again later.

​
AIWA uses Neon Postgres

AIWA uses Neon Postgres as the database infrastructure for your project. Postgres is a relational database, which means your application can store structured information and create relationships between different types of data. For example, a CRM might have:
  • Users
  • Leads
  • Properties
  • Deals
  • Follow-ups
Those records can also relate to each other.
This makes it possible to build applications where information is connected rather than stored as isolated pieces of content.

​
Your project gets its own database

When an AIWA project requires persistent application data, AIWA can provision the Neon database infrastructure for that project. This keeps the application’s data associated with the project you’re building. You don’t need to begin by:
  • Creating a Neon project manually
  • Creating database tables yourself
  • Configuring a database server
  • Wiring the database into your application
  • Writing SQL before you can start building
Instead, you can begin with the product requirement. For example:
Build a lead management system where agents can create leads, assign them to team members, update their status, add notes, and schedule follow-ups.
AIWA can determine what data structures are needed to support that experience.
AIWA handles the database infrastructure required by supported projects, allowing you to focus primarily on your application’s data and behavior rather than initial database configuration.

​
From your prompt to your database

You don’t need to describe your database using technical terminology. Suppose you tell AIWA:
Add lead management to the application. Each lead should have a name, email, phone number, source, status, assigned agent, budget, property interest, and notes.
From that product requirement, AIWA can determine that the application needs a Lead data structure containing information similar to:
AIWA can then build the application functionality around that data. The user sees a lead management experience. Behind the interface, the application has structured data it can save and retrieve.

​
Data persists

Database-backed information persists beyond the current page view. For example, imagine an agent creates:
The application can save that information to its database. When the agent returns later, the application can retrieve Sarah’s record again. The same principle applies to:
  • Customer profiles
  • Bookings
  • Orders
  • Tasks
  • Messages
  • Properties
  • Projects
  • Settings
  • Other dynamic application data
This is what makes your application stateful rather than simply a collection of static screens.

​
Tables organize your data

Relational databases organize information into structures commonly called tables. For example, an agency application might have:
  • Customers
  • Projects
  • Tasks
  • Invoices
A Customers table might contain information such as:
A Projects table might contain:
You don’t necessarily need to create these structures manually. Describe the information your application needs, and AIWA can build the appropriate data structures as part of the application.

​
Your data can have relationships

Real applications rarely contain completely isolated data. A project might belong to a customer. A task might belong to a project. An order might belong to a customer. A deal might connect a lead with a property. These are relationships. For example:
One customer could have multiple projects, and each project could contain multiple tasks. Or in a real estate CRM:
Relationships allow different parts of your application to work together.

​
Describe relationships naturally

You don’t have to say:
Create a foreign key between these database tables.
You can describe the product behavior instead. For example:
Every project should belong to a customer, and a customer should be able to have multiple projects.
Or:
Each deal should be connected to a lead, a property, and the agent responsible for the deal.
Or:
A customer should be able to place multiple orders, and every order should show which customer placed it.
These requirements tell AIWA how the information in your product relates. AIWA can translate that intent into the underlying implementation.

​
Your database evolves with your application

Your first database structure doesn’t have to represent every feature you’ll ever build. Suppose your first version has:
  • Customers
  • Projects
Later, you tell AIWA:
Add tasks to projects.
Your application now needs another type of data:
Later:
Allow users to comment on tasks.
Now the application evolves again:
Your data model can grow as your product grows.

​
Adding fields later

You can also extend existing data. Suppose your Lead records currently contain:
  • Name
  • Email
  • Phone
  • Status
You later decide you need more information. You can tell AIWA:
Add source, budget, assigned agent, and property interest to leads. Update the create and edit forms and show the new information on the lead detail page.
AIWA can update the application around the expanded data requirements. For significant database changes, consider using Plan Mode first so the impact can be reviewed before implementation.

​
Changing existing data structures

Some database changes are more significant than simply adding a field. For example:
Allow projects to belong to multiple customers instead of one customer.
Or:
Convert the existing single-user data model into workspace-based data where every record belongs to an organization.
These changes can affect:
  • Existing records
  • Relationships
  • APIs
  • Permissions
  • Application logic
  • User interfaces
For changes like these, use Plan Mode, particularly if the application already contains important data.
Be especially careful with structural changes to applications containing real production data. Ask AIWA to analyze the existing data model and plan the migration before making major changes.

​
Your interface talks to your database

The database usually works behind the scenes. Users interact with your application’s interface. For example, when someone completes:
the application can send that information to the appropriate server-side functionality, which saves the record. When the Leads page opens, the application retrieves the relevant lead records and displays them. Conceptually:
And when reading information:
AIWA can build these pieces together.

​
Database actions

Most database-backed applications rely on four fundamental types of operations. Create Add new information.
Create a lead.
Read Retrieve existing information.
Show all active leads.
Update Change existing information.
Change this lead’s status to Qualified.
Delete Remove information.
Delete this lead.
Developers often refer to these operations collectively as CRUD. You don’t need to use that terminology when prompting AIWA. Simply describe what users should be able to do.

​
Filtering and searching your data

Once your application contains data, users often need ways to find the right records. For example:
Add search to the Leads page so users can search by name, email, or phone number.
Or:
Allow agents to filter leads by status, source, and assigned agent.
Or:
Show only bookings scheduled for today.
AIWA can build interfaces and application logic around the information stored in your database.

​
Dashboards can use real data

Database-backed applications can calculate metrics from stored information. For example, a sales dashboard might show:
These figures can be derived from application data rather than being hard-coded placeholders. You can describe the metric you want:
Show the total value of all deals that haven’t been won or lost.
Or:
Show how many new leads were created this month compared with last month.
AIWA can build the required data logic around the request.

​
Keep private data private

Database credentials and sensitive connection information should not be exposed in client-side interfaces or hard-coded into public application code. AIWA’s application architecture should keep sensitive database operations in the appropriate server-side environment.
Never paste database passwords, connection strings, or other private credentials into public-facing page content or expose them directly in frontend code.
If a workflow requires credentials or secrets, use the appropriate secure configuration or connector flow provided by AIWA.

​
Database vs authentication

Your database and authentication solve different problems. Database Stores application information. Examples:
  • Customers
  • Projects
  • Orders
  • Bookings
  • Deals
Authentication Determines who the user is. Examples:
  • Leon is signed in
  • Sarah is signed in
  • Marcus is signed in
The two can work together. For example:
Show each user only the projects that belong to their account.
Authentication tells the application who the user is. The database contains the projects and their ownership information. Application logic determines which records that user should be allowed to access. We’ll cover authentication on the next page.

​
Database vs application logic

The database stores information, but it doesn’t define the entire product experience. Suppose you have:
Your application logic might define:
When a deal moves to Closed Won, record the completion date and add its value to the won revenue metric.
The database stores the information. The application logic determines what should happen. AIWA can work across both.

​
You can be technical if you want

AIWA allows you to describe requirements at the level you’re comfortable with. A non-technical user might say:
Every customer should be able to have multiple projects.
A developer might provide more explicit requirements about:
  • Data relationships
  • Field types
  • Validation
  • Indexes
  • Constraints
  • Queries
  • API behavior
  • Migration requirements
Both approaches can be useful. You don’t need to become a database engineer to build database-backed products with AIWA, but technical users can still provide detailed direction when needed.

​
Example prompts

Here are some examples of natural-language requests that require database functionality. Booking application
Customers should be able to book appointments. Store the customer, service, staff member, appointment date, time, and booking status.
CRM
Add leads with name, email, phone, company, source, status, assigned agent, estimated value, and notes.
Project management
Each workspace should have projects. Projects should contain tasks, and tasks can be assigned to workspace members.
E-commerce
Store products, customers, orders, and order items. Customers should be able to view their previous orders after signing in.
Property platform
Allow agents to create property listings with title, location, price, property type, bedrooms, bathrooms, description, and listing status.
You describe the product requirement. AIWA handles the database-backed implementation required to support it.

​
The principle

You shouldn’t have to start product development by designing database tables. Start with:
What information does my product need?
Then:
How should that information relate?
Then:
What should users be able to do with it?
AIWA can help translate those answers into a working Neon-backed application.

​
Next: Authentication

Your database gives your application persistent information. But many applications also need to know: Who is using the application? Next, we’ll look at Authentication: how AIWA can add Google and email/password sign-in, protect application areas, and build experiences around authenticated users.

Authentication

Add Google and email/password sign-in and protect application areas.