Most work does not start on a blank page. It starts in a spreadsheet that grew too big, a folder of PDF invoices, an old Access file nobody can open any more, or a photo of a paper form. QuintaDB reads all of those and turns them into a database you can search, filter, share and hand to your team.
Import your fileThis is the road most people take. Upload an .xls, .xlsx, .csv or .txt file and QuintaDB reads the first row as your column names and every row below it as a record. You do not create the fields first — the file describes them, and the form is built to match.
Real exports are rarely clean, so the importer expects mess. If the file opens with a company header, a report title or a few blank rows before the actual table, the header row is detected and you are told which row was chosen, with the option to pick another. Numbers, dates, links and email addresses are recognised by what they contain, so a column of dates behaves like dates afterwards — sortable, filterable, usable in a calendar — and not like text that merely looks like dates.
Exports out of accounting software, warehouse systems and 1C behave the same way. You do not have to clean the file by hand first; upload what the system gave you.
Not every table exists as a file. Some live on paper, some inside a program that has no export button, some in a PDF a supplier emailed you.
Photograph the sheet, or take a screenshot of the window, and upload the image. The table is read out of the picture and becomes rows and columns you can correct before anything is saved. The same works for PDF — invoices, price lists, statements and finished reports — where copying by hand is the only alternative.
Two things decide whether this goes well: the whole table has to fit in the frame, and the text has to be readable at full size. A photo taken at an angle across half the sheet will lose the columns on the edge. Reading runs in the background, so you can keep working while it finishes.
Access files are the classic dead end. The database still holds years of work, but the machine that ran it is gone, the licence expired, or the file simply will not open on a Mac.
Upload the .mdb or .accdb file. Its tables are listed, you choose the ones you need, and each becomes its own table in your project with the columns it had. Relationships declared in the original file are not thrown away — where one table pointed at another, you are offered the same link here, so an order still knows its customer.
If the data already lives online, you do not have to download it first. Paste a link to a Google Sheets document, a file in Google Drive or Dropbox, or any address that returns a file, and it is fetched and imported.
A link can also stay connected. Turn on automatic refresh and the file is re-read on a schedule, so a sheet your colleagues keep editing stays in step with your database without anyone remembering to export it again. This is the difference between a one-off migration and a spreadsheet that quietly becomes the front end of a real system.
Airtable bases are imported through Airtable's own interface: you give the base link and an access token, and the tables come across with their fields. Where a base links records to another table, that connection is carried over rather than flattened into text.
Notion exports arrive as a ZIP archive — choose "Markdown & CSV" when exporting, upload the archive as it is, and the tables inside it are unpacked together instead of one file at a time. The same works for any ZIP with several spreadsheets in it.
JSON files are read as well, which covers exports from other services and anything an API handed you.
And for the smallest case there is no file at all: copy a block of cells from a spreadsheet and paste it. Ten rows do not deserve an export.
Nothing is written until you have seen it. You get a mapping screen: every column of your file on the left, and where it will land on the right. Columns that clearly match are matched for you and marked as such; the rest wait for your decision. Any column can go into an existing field, become a new field, or be skipped entirely — files usually carry a few columns nobody needs.
When one table refers to another — an order that names a customer, a task that names a project — you are told how many values actually match on the other side before the link is created. If the target table has duplicates, you are warned, because the match will attach to the first of them.
After the import you see how many records arrived and whether any column came in empty. An empty column is almost always the file's fault — an extra row above the headers, or merged cells — and the message says so, so the fix is one corrected file rather than an afternoon of guessing.
Most imports are not a single event. A price list is re-sent every month, a report is exported every week, a colleague keeps editing the same sheet.
Choose a key column — an order number, an article code, an email address — and the next import updates the records that already exist instead of adding second copies of them. Rows the file does not contain are left alone. This is what makes an import safe to repeat, and it is worth setting up on the very first upload rather than after the duplicates appear.
If you would rather follow a walkthrough with pictures than read a summary, the detailed guide covers the whole path from file to working database: how to import Excel and CSV files into an online database.
There is no separate tool to install and no import plan to buy. Create a project, press Import, and upload whatever you have — a spreadsheet, an old database, a photograph of a page. What arrives is not a copy of your file: it is a table with its own forms, permissions and links, which your colleagues and clients can use without ever seeing the file it came from.
Ready-made structures you can adapt to your own process.