English

Your Database

condoo.Vibe provisions Neon Postgres per project and lets you describe the data your product needs in plain language instead of SQL.

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.

condoo.Vibe uses Neon Postgres to provide persistent database infrastructure for applications that need it.

When your application requires stored data, condoo.Vibe can create and work with the database as part of building your product.

You describe the data your product needs. condoo.Vibe 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:

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.

condoo.Vibe uses Neon Postgres

condoo.Vibe 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:

Those records can also relate to each other.

Lead → Deal → Property
         ↓
       Agent

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 condoo.Vibe project requires persistent application data, condoo.Vibe 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:

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.

condoo.Vibe can determine what data structures are needed to support that experience.

From your prompt to your database

You don't need to describe your database using technical terminology.

Suppose you tell condoo.Vibe:

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, condoo.Vibe can determine that the application needs a Lead data structure containing information similar to:

Lead
├── Name
├── Email
├── Phone
├── Source
├── Status
├── Assigned Agent
├── Budget
├── Property Interest
├── Notes
├── Created Date
└── Updated Date

condoo.Vibe 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:

Name: Sarah Chen
Email: sarah@example.com
Status: Qualified
Budget: $850,000
Source: Website

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:

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:

A Customers table might contain information such as:

Customer
├── Name
├── Email
├── Phone
├── Company
├── Status
└── Created At

A Projects table might contain:

Project
├── Name
├── Customer
├── Status
├── Budget
├── Start Date
├── Due Date
└── Created At

You don't necessarily need to create these structures manually.

Describe the information your application needs, and condoo.Vibe 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:

Customer
   ↓
Project
   ↓
Task

One customer could have multiple projects, and each project could contain multiple tasks.

Or in a real estate CRM:

Lead ──────┐
           ↓
          Deal
           ↑
Property ──┘
           │
           ↓
         Agent

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 condoo.Vibe how the information in your product relates.

condoo.Vibe 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:

Later, you tell condoo.Vibe:

Add tasks to projects.

Your application now needs another type of data:

Customers
    ↓
Projects
    ↓
Tasks

Later:

Allow users to comment on tasks.

Now the application evolves again:

Customers
    ↓
Projects
    ↓
Tasks
    ↓
Comments

Your data model can grow as your product grows.

Adding fields later

You can also extend existing data.

Suppose your Lead records currently contain:

You later decide you need more information.

You can tell condoo.Vibe:

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.

condoo.Vibe 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:

For changes like these, use Plan Mode, particularly if the application already contains important data.

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:

Add Lead

Name: Marcus Okonkwo
Email: marcus@example.com
Budget: $1,200,000
Status: New

[Create Lead]

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:

User
  ↓
Application Interface
  ↓
Server-Side Logic
  ↓
Neon Postgres

And when reading information:

Neon Postgres
  ↓
Server-Side Logic
  ↓
Application Interface
  ↓
User

condoo.Vibe 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 condoo.Vibe.

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.

condoo.Vibe 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:

Total Leads        1,248
Active Deals          37
Pipeline Value   $4.2M
Deals Won             18

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.

condoo.Vibe 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.

condoo.Vibe's application architecture should keep sensitive database operations in the appropriate server-side environment.

If a workflow requires credentials or secrets, use the appropriate secure configuration or connector flow provided by condoo.Vibe.

Database vs authentication

Your database and authentication solve different problems.

Database

Stores application information.

Examples:

Authentication

Determines who the user is.

Examples:

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:

Deal
├── Value
├── Stage
└── Expected Closing Date

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.

condoo.Vibe can work across both.

You can be technical if you want

condoo.Vibe 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:

Both approaches can be useful.

You don't need to become a database engineer to build database-backed products with condoo.Vibe, 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.

condoo.Vibe 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?

condoo.Vibe 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 condoo.Vibe 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.