On this page
Short answer: a database application is software that sits on top of a database and lets people work with the data without touching the database itself. The database stores the records. The application adds the screens (forms, lists, dashboards), the rules (who can see and change which records) and the automation (what happens when a record changes). A CRM, an inventory system, a school's student records and a client portal are all database applications. You can buy one made for your job, write one in code, or build one on a platform that gives you the database and the application together, which is what Tadabase AI does from a description. This guide covers the parts, examples, the types, and how to choose a way to build one.
Describe the database you need — we’ll build it now, free.
We started the prompt for you. Edit it, or describe your own app.
The four parts of a database application #
A database is where the data lives: tables of records, each field with a type, and links between tables. A database application is the layer people actually use. Every working database application has the same four parts:
| Part | What it does | Example in a client database |
|---|---|---|
| Data | Tables, typed fields and links between tables | Clients, contacts, projects and invoices; one client has many invoices |
| Screens | Forms to enter records, lists and detail pages to find them, dashboards and reports to sum them up | A form for a new client; a list of overdue invoices; revenue by month |
| Access rules | Logins, roles, and which records each person can read or change | Staff see the clients assigned to them; each client sees only their own invoices |
| Automation | Checks, calculations and workflows that run when a record changes or on a schedule | Email the client when an invoice is issued; remind the account owner 7 days before it is due |
Take away the screens and the rules and you have a database that someone has to query by hand. Take away the data structure and the rules and you have a shared spreadsheet that everybody can edit.
Examples of database applications #
Most of the software a business runs on is a database application with a job-specific name:
| Application | Main tables | Who logs in |
|---|---|---|
| CRM or client management | Clients, contacts, deals, activities | Sales and account staff |
| Inventory and order management | Products, locations, stock movements, orders, suppliers | Warehouse, purchasing and sales staff |
| School management | Students, guardians, classes, attendance, grades | Teachers, office staff and sometimes parents |
| Patient intake and case management | Patients, intake forms, appointments, case notes | Clinicians and front desk; health-data rules apply |
| Property management | Properties, units, tenants, leases, maintenance requests | Managers, tenants and contractors |
| Job and project tracking | Clients, jobs, tasks, time entries, invoices | Office staff and people in the field |
| Client portal | The business's own tables, filtered to the logged-in client | Customers |
Many of these start life as a spreadsheet and become a database application when more than a few people need to change it, or when people outside the team need to see their own part of it.
Spreadsheet vs. database vs. database application #
The three get confused because they can hold the same rows. The difference is who uses them and what stops mistakes:
| What differs | Spreadsheet | Database | Database application |
|---|---|---|---|
| Who works in it | Anyone with the file | Developers and admins, through SQL or a console | Everyone, through forms and pages |
| Structure | Cells; one sheet rarely links cleanly to another | Typed fields and linked tables | The database's structure, with screens on top |
| Access | Per file | Per database user or table | Per role, and in good ones per record |
| Automation | Formulas and scripts | Triggers and stored procedures | Workflows: emails, approvals, reminders, documents |
| Best for | Analysis, models, one-off lists | Storing data for software | Running a process that several people share |
Types of database applications #
- Desktop database applications. They run on one computer, with the data in a local file or on an office server. Microsoft Access is the best-known example; Microsoft lists Access as available for PC only, included in Microsoft 365 subscriptions or sold as Access 2024. A good fit for a few people in one office; awkward for remote staff, Macs, phones and customers.
- Web-based database applications. They run in a browser with the data on a server, so staff, contractors and customers can log in from anywhere. Most new database applications are built this way.
- Mobile database applications. A phone screen on the same data for people in the field: technicians, inspectors, drivers. Often this is the web application itself, laid out for a phone.
- Off-the-shelf or custom. Packaged software fits a common process quickly. A custom database application fits your process, your fields and your rules, at the cost of building it.
People also sort database applications by the database underneath. Relational (SQL) databases store linked tables and suit most business records: clients, orders, invoices, students. Document and other NoSQL databases suit very large or loosely structured data. For a business application, relational is the usual default, and with a builder you rarely have to choose.
How to build a database application #
There are five common ways. The time column is a typical first version, not a promise:
| Approach | What you do | Typical first version | Trade-off |
|---|---|---|---|
| Write it in code | Design the schema, write the back end and API, the screens, logins and hosting | Weeks to months | Full control; you maintain every part |
| Desktop builder | Tables, forms and reports in one file | Days | Hard to share beyond one office |
| Spreadsheet-style database | Tables with linked records and views | Hours | Built for a team; customer logins and per-record rules are limited or extra |
| No-code app builder | Data, pages and rules configured visually | Days | You learn the builder |
| AI app builder | Describe the app; the AI builds the tables, screens and rules; you refine | Minutes, then refinement | Check that logins, roles and rules are real and run on the server |
Whichever way you go, check these before you commit:
- Who logs in. Staff only, or customers, contractors and partners too? Are you charged per user or per plan?
- Per-record rules. Can a rule limit each person to their own records, enforced on the server rather than hidden on the page?
- Linked tables. One client, many invoices. Can you change a field type or add a link later without rebuilding?
- Automation. Can workflows run when a record changes and on a schedule?
- Getting data out. CSV export at any time, and an API for other systems.
- Size. How many records will you have in three years, and what does the plan allow?
- Regulated data. For health or student records, check what the vendor signs and what you have to configure yourself.
Build a database application with Tadabase AI #
Tadabase AI builds the database application from a description: tables, links, roles, row-level rules, forms and workflows, on a backend that is already running, so there is no server to set up. Describe what the app tracks and who touches it. For example:
A job tracking app for our cleaning company: clients, sites, jobs, staff and invoices. Office staff see everything, cleaners see only the jobs assigned to them and mark them done from their phone, and each client logs in to see their own jobs and invoices. Email the client when a job is marked done, and remind the office about unpaid invoices every Monday.
The AI builds the tables, roles, rules and workflows with sample data. Then refine what it built:
- Your data. Import what you have as CSV, one file per table, mapping columns to fields. Changing a field type or adding a link between tables is a setting, not a rebuild.
- Who sees what. Roles plus row-level security: a policy can limit a role to the records connected to the logged-in user, and the rule runs on the server.
- Screens. Forms, lists, detail pages, and reports with count, sum, average, minimum and maximum summaries.
- Automation. Workflows on record changes or on a schedule: emails from templates, status updates, PDFs generated from a record.
- Getting data out. Export any table to CSV at any time; full REST API access on Pro and above.
- Room to grow. Unlimited app users on every paid plan, from 25,000 records per app on Starter up to 500,000 on Business.
Common questions #
What is a database application in simple terms? Software people use to enter, find and update shared records, such as clients, orders or students, without working in the database directly.
What are examples of database applications? CRMs, inventory and order systems, school management systems, patient intake and case management, property management, job tracking and client portals.
What is the difference between a database and a database application? The database stores the data. The application is what people use to work with it: forms and pages, rules about who sees what, and automation.
Is Excel a database application? No. Excel is a spreadsheet, built for calculating and analysing, and access is per file rather than per record. Microsoft's database application builder is Access.
Is Microsoft Access still a good choice? For a few people on Windows PCs in one office, it can be. Microsoft lists Access as PC only, so staff on Macs or phones, and customers outside the company, need a web-based database application instead.
Do I need to know SQL to build one? Not with a no-code or AI app builder such as Tadabase AI. Writing one from scratch usually means SQL or a data library, plus a back end, a front end and hosting.
How much does it cost to build a database application? Custom development is paid in developer time. On Tadabase AI you can start on the free plan, with 5 credits a day plus a one-time 300-credit welcome bonus and no card; the Starter plan is $25 a month.
Where to start #
Write down the three things the application must track and who touches each one. If nobody outside your team needs to log in, a spreadsheet-style database may be enough, and tadabase.com/blog/free-online-database compares the free ones. If customers, contractors or field staff need to see their own records, describe the app to Tadabase AI and refine what it builds.