MS Access Endpoint

⚠️ Know the Limits of MS Access

MS Access is a file-based desktop database — it was never designed as a high-concurrency network server. Before deploying the endpoint in production, be aware of these inherent limitations:

• Performance degrades under concurrent load. Access uses file-level locking. More than a handful of simultaneous read/write connections will contend for the same .accdb file, and query throughput drops sharply.
• Multi-user ceiling is low. Practical limits are ~5–10 concurrent users for mixed read/write workloads. Beyond that, expect lock contention, timeouts, and Jet engine errors.
• Security is file-system-level. Access has no row-level security, no user accounts, and no audit logging. The optional database password provides only nominal protection. TLS encrypts the wire — it does not harden the database itself.
• Index and primary key visibility depends on DAO. The endpoint extracts indexes and primary keys through the DAO TableDef.Indexes collection. If your database was created without explicit indexes (e.g. imported data with field-level primary keys only), the pg_index and pg_constraint catalog tables will appear empty.

Need more scale? Consider keeping your Access data where it is and replicating it into a server-grade database. The endpoint gives you the connection — a replica gives you the performance, concurrency, and security that Access alone cannot provide.

🔄 Learn about Replicator — MS Access-to-Server Database Synchronisation

Replicate your Access data to PostgreSQL, MySQL, or SQL Server while leaving your original .accdb untouched. Your Access application keeps working. Your web apps and analytics get a real database.