Bridging FileMaker and the Modern Web

TL;DR

• You don't need to replace FileMaker to build modern web apps — connect it to PostgreSQL instead
• Three proven sync methods: REST API (cleanest), ODBC/JDBC (fastest), webhooks (real-time)
• Most businesses are well-served by a 15-minute scheduled sync
• A pilot sync project typically takes one week; full implementation runs 2–4 weeks

---

Why Businesses Are Doing This

If your business runs on FileMaker, you've invested years into it — custom logic, trained staff, and processes that work. The challenge is that modern web portals, mobile apps, and cloud integrations typically expect a different kind of database on the backend.

The answer isn't to throw out FileMaker. It's to bridge the two systems: keep FileMaker for what it does best, and use PostgreSQL as the engine that powers your customer-facing applications.

FileMaker handles your operations. PostgreSQL powers your web and mobile apps. Both run in parallel.

Two Sync Architectures

Depending on your use case, there are two main patterns to consider.

One-way sync (FileMaker → PostgreSQL) is the simpler option and works well for most businesses getting started — customer portals, inventory displays, and analytics dashboards. Complexity is low and the data flow is predictable.

Bi-directional sync allows customers or field staff to write data back into the system — useful for online orders and collaborative data entry. It's more involved and requires a conflict resolution strategy, but opens up powerful self-service workflows.

Three Ways to Implement It

There's no single right way to connect FileMaker to PostgreSQL. Here are the three proven approaches, each with trade-offs.

REST API — Official and well-documented with OAuth support. The cleanest and most maintainable approach for most clients. Requires FileMaker Server licensing and is subject to rate limits.

ODBC / JDBC — Fast, direct database access with no API call limits. Ideal for high-volume or performance-sensitive use cases. Requires driver setup and typically a VPN for remote access.

Script Triggers + Webhooks — Real-time, event-driven, with custom logic. Best when data freshness is critical. More complex error handling is required.

For most clients, we start with the REST API method. For high-volume scenarios, ODBC/JDBC gives direct database access without API overhead. Webhooks are reserved for when data latency genuinely impacts the user experience.

How Often Should Data Sync?

Sync frequency depends on your business requirements.

Real-time triggers are best for e-commerce and critical updates — latency under 1 second, but higher infrastructure cost. Scheduled sync (every 5–60 minutes) works well for most business applications with moderate cost. Nightly batch processing is the lowest cost option and suits reporting and analytics workloads.

Most business applications are well-served by a 15-minute scheduled sync. Real-time sync introduces more infrastructure complexity and is only needed when data latency actually impacts the user experience.

Data Type Mapping

One of the less glamorous but critical parts of any sync project is mapping FileMaker's field types to PostgreSQL equivalents. Getting this wrong causes data loss or corruption.

• Text → VARCHAR / TEXT — set appropriate length limits
• Number → NUMERIC / INTEGER — preserve decimal places
• Date / Time → DATE / TIME — handle timezone carefully
• Timestamp → TIMESTAMP WITH TZ — always include timezone info
• Container → BYTEA / VARCHAR — store as URL reference or binary
• Calculation → Computed column / Function — recreate logic in PostgreSQL

Handling Edge Cases

Deleted Records

When records are deleted in FileMaker, a soft-delete approach is recommended — marking records as deleted rather than removing them. This keeps data integrity intact and gives you an audit trail.

Conflict Resolution

For bi-directional sync, you need a strategy for when both systems update the same record. Options include last-write-wins (simple but lossy), timestamp-based merging, or flagging conflicts for manual review.

Large Data Volumes

Incremental sync — only transferring records changed since the last run — keeps sync fast even with large databases. Batch processing in chunks of ~1,000 records prevents timeouts and keeps things stable.

Security & Monitoring

A production sync setup should include:

• Environment variables for all credentials (never hardcoded)
• HTTPS / SSL-encrypted connections throughout
• A read-only PostgreSQL user for your web application
• Sync logs tracking records processed, failed, and duration
• Alerts for sync failures or unusual error rates

What Does Implementation Look Like?

A typical FileMaker-to-PostgreSQL sync project follows this path:

1. Schema Assessment — Map your FileMaker tables and identify what needs to be synced

2. Choose Your Approach — REST API, ODBC, or webhook triggers

3. Pilot on One Table — Prove out the sync before expanding

4. Scale to Full System — Bring in remaining tables and relationships

5. Monitor & Maintain — Track sync health and handle schema changes

Most clients are up and running with a pilot sync within a week. Full system sync is typically 2–4 weeks depending on complexity.

Ready to connect your FileMaker system to the modern web? Let's talk about your requirements.

---

Frequently Asked Questions

Can I connect FileMaker to a modern web app without replacing it? Yes. The most practical approach is a two-system architecture: FileMaker handles your internal operations, while PostgreSQL powers your web or mobile app. Data syncs between them on a schedule or in real time. You keep FileMaker intact and gain modern capabilities without a full rebuild.

What's the best way to sync FileMaker to PostgreSQL? For most businesses, the REST API is the right starting point — it's official, well-documented, and maintainable. For high-volume scenarios where API rate limits are a concern, ODBC/JDBC gives direct database access. Script triggers with webhooks are reserved for cases where real-time data freshness is genuinely critical.

How often should FileMaker data sync? It depends on your use case. Most business applications are well-served by a 15-minute scheduled sync. E-commerce or live inventory use cases may need real-time triggers. Reporting and analytics can often run on nightly batch jobs. Real-time sync adds infrastructure complexity — only use it when data latency actually impacts users.

What happens to deleted records during sync? We recommend soft-deletion — marking records as deleted rather than physically removing them. This preserves your audit trail and prevents referential integrity issues in PostgreSQL. It also gives you the ability to recover accidentally deleted data.

How long does a FileMaker integration project take? A pilot sync on one table is typically up and running within a week. Scaling to a full system sync generally takes 2–4 weeks depending on the number of tables, the sync method chosen, and how much custom conflict-resolution logic is required.