How Rizq AI moved 49,500 job-board rows from Airtable to PostgreSQL

Rizq AI is building a job-automation product: search, match, apply. Airtable could hold early data, but it could not stay the backend of that application: rate limits, Airtable's model, and no real ownership as they scaled. They moved to PostgreSQL they control. AT Migrator migrated 49,500 rows across 5 tables and 95 fields, including 11,997 attachments, with formulas intact.

Who is Rizq AI?

Rizq AI is a job-automation product: finding roles, tailoring resumes, and helping people apply. It is founded by Arbaz Yasin Nivsekar, Founder & CEO.

Early on, a lot of the operational data for that product lived in Airtable. That is common. It stops working when Airtable has to act like the engine of the application.

Why leave Airtable?

The goal was never “leave Airtable for its own sake.” The goal was to build a custom application that could grow, and to own the data that application runs on.

Airtable caps how hard a product can push the API. It also decides how relationships and business logic work. For a spreadsheet-style workflow that is fine. For a product backend it becomes a wall: rate limits, and a model that is not yours to reshape.

PostgreSQL is where that product belongs. The data is theirs. They control access and how the system scales. Leaving Airtable only works if the hard parts arrive intact: attachments that applications still open, and formulas that still mean something after cutover.

What was in the base

The Airtable base held their hiring / job-board dataset (the records the product depended on) plus a large attachment footprint (11,997 files). In total: 49,500 rows across 5 tables and 95 fields, with linked records between the main entities.

That mix is where CSV-and-hope migrations fail. You can dump cell text. You cannot casually recreate relationships, computed fields, and file URLs a product still needs the next day.

What AT Migrator did

We ran the same pipeline we use for production cutovers:

• Schema and relationships: tables mapped to Postgres; linked records became foreign keys or junction tables so the dataset stayed connected.
• Formulas and rollups: recreated as SQL so values recalculate from source data instead of freezing the last Airtable snapshot.
• Attachments: files transferred to storage they control; Postgres kept stable references (metadata and URLs), not expiring Airtable links.
• Validation: row counts and spot-checks on both sides before treating the cutover as done.

“Airtable was excellent for the early version. Once we needed a custom product we could control our own way, it stopped fitting the business. We tried migrating ourselves and with other tools, but nothing fully worked. Formulas and linked records felt impossible until we found AT Migrator.”

Outcome

The product's data now lives in PostgreSQL under Rizq AI's control. They can build and grow the application without Airtable's rate limits or model deciding what ships. Attachments and formula logic came across in the migration, so the cutover was something they could trust, not a cleanup project waiting to happen.

If Airtable is still the backend of a product you intend to scale, start with a migration plan or book a discovery call. We will scope records, attachments, and formula risk before you pay.