Mathesar

Mathesar is an open-source web application that gives non-technical users and developers alike a powerful, spreadsheet-style interface to view, edit, query, and collaborate on PostgreSQL data directly. Unlike Airtable-style tools that introduce their own data layer, Mathesar works directly with your existing Postgres schemas, tables, constraints, and roles — no data migration, no proprietary formats, no vendor lock-in.

Deployed in minutes via Docker and maintained by Mathesar Foundation (a 501(c)(3) nonprofit), the application provides a production-grade data management layer without requiring SQL knowledge. It inherits PostgreSQL’s battle-tested access control model: roles you define in Postgres are the roles users see in Mathesar, and permissions stay enforced at the database level.

Mathesar is built on a dual-layer architecture: a Django-based JSON-RPC backend that delegates core schema logic to PL/pgSQL stored procedures inside your database, and a Svelte frontend that provides a fluid, type-aware data editing experience. The result is a tool that scales with your database and integrates naturally into any existing PostgreSQL-centric infrastructure.

What You Get

• Direct Postgres integration - Connects to any existing PostgreSQL database without migrating data; works with your real schemas, tables, foreign keys, types, and constraints exactly as defined.
• Spreadsheet-like table editing - View, create, update, and delete records in a familiar grid interface with inline editing, row-level saves, and support for any Postgres data type.
• Visual query builder (Data Explorer) - Build complex queries with filters, sorts, grouping, joins, and aggregations through a point-and-click interface — no SQL knowledge required.
• Postgres-native access control - Uses existing PostgreSQL roles and privileges; permissions are enforced at the database level, not just the application layer.
• Shareable form builder - Create public or private data entry forms with a unique link; submissions are saved directly as new records in your Postgres tables.
• Schema and table management - Create, rename, and modify schemas, tables, and columns through the UI; column migrations between tables take two clicks.
• Relationship navigation - Foreign key relationships are surfaced as navigable links in the UI; nested records are discoverable without writing joins.
• Import and export - Import CSV and Excel files into tables and export table data or query results as CSV or JSON for use in other tools.
• Multi-database support - Connect and manage multiple Postgres databases from a single Mathesar instance, each with independent schema and permissions.
• Internationalization - Full UI localization via svelte-i18n with compile-time translation extraction; the app ships with support for multiple languages.

Common Use Cases

• Non-technical admin panel - A developer deploys Mathesar as a self-hosted admin interface over an existing production Postgres database, replacing hand-built CRUD dashboards for internal operations staff.
• Data collection via forms - A nonprofit builds shareable intake forms for grant applications, volunteer sign-ups, or event registrations, with submissions landing directly in structured Postgres tables.
• Operational data exploration - A business analyst explores customer and order data by filtering, grouping, and joining tables without needing SQL or access to a BI tool.
• Inventory and asset tracking - A warehouse team manages equipment, stock, and supplier records using a spreadsheet-style interface while developers retain full database access for reporting.
• Research data management - A university research team stores experiment data in structured Postgres tables and uses Mathesar to allow collaborators to enter and review records without database credentials.
• Legacy database modernization - An organization with an existing Postgres database gains a modern UI layer for staff data entry without rewriting the application or migrating to a SaaS tool.

Under The Hood

Architecture Mathesar follows a layered monolithic architecture where Django handles HTTP routing through URL patterns that split into two distinct concerns: traditional view controllers for HTML page delivery, and a central JSON-RPC endpoint that handles all data operations. The RPC layer delegates to a db/ package of pure data-access functions, but the genuinely distinctive architectural choice is that the core logic for schema introspection, type inference, and joinable-table discovery lives inside PL/pgSQL stored procedures loaded directly into the user’s PostgreSQL instance — making the database itself a first-class logic host rather than a passive store. The Svelte frontend communicates exclusively through the typed RPC contract. Separation of concerns is sound at the macro level; the main architectural weakness is that some view-layer code mixes HTTP handling with business rules, and there is no formal dependency injection, with database connections managed through context utilities.

Tech Stack The backend runs Python 3.14 with Django 4.2 as the application framework, using a deliberate combination of SQLAlchemy 1.4 for schema introspection and psycopg3 (binary) for record operations — an unusual pairing that lets Mathesar exploit SQLAlchemy’s reflection capabilities while keeping record I/O on the faster, async-capable psycopg3 path. PostgreSQL serves as both the primary database and the logic host for stored procedures implementing schema graph traversal, type casting, and custom aggregates. The frontend is Svelte 3 with TypeScript 4.8, built with Vite and bundled with Terser, served through Caddy with WhiteNoise for static assets. Authentication is handled by django-allauth with pluggable OIDC/SSO via a YAML-configured SSO module. Object storage integrations (Azure Blob, S3-compatible via s3fs, and MinIO for local development) are available for file attachment features. Internationalization uses svelte-i18n with compile-time extraction. Deployment is Docker-first with multi-stage Dockerfiles and Caddy for production TLS.

Code Quality Test coverage is comprehensive across all layers: approximately 50 Python test files using pytest with Django’s test harness, around 34 frontend test files using Vitest and testing-library/svelte, and a dedicated SQL test suite that validates the PL/pgSQL stored procedures in isolation. A standout quality investment is the structured exception taxonomy in the RPC error layer, which maps exception classes from six subsystems (builtins, psycopg, Django, SQLAlchemy, Mathesar internals, and the db library) to unique negative integer codes using an immutable frozendict — giving the frontend client deterministic, parseable error information for any failure mode. TypeScript strict mode is enabled with the airbnb-typescript ESLint ruleset and Svelte’s component prop typing. Naming conventions are clear and domain-driven throughout both Python and Svelte layers. The main quality constraints are the SQLAlchemy 1.4 pin (the older branch) and some view-layer code that mixes concerns.

What Makes It Unique Mathesar’s most technically distinctive decision is pushing schema introspection, type inference, and relational discovery into PL/pgSQL stored procedures that live inside the target database rather than reimplementing this logic in Python. The db/sql/ layer ships functions for type casting, custom aggregates, and schema graph traversal that are installed into the user’s own Postgres installation, meaning query capabilities scale with PostgreSQL itself and there is no application-layer bottleneck for schema analysis. The structured JSON-RPC error taxonomy — where every throwable exception across six subsystems gets a unique negative integer code — is unusually precise for an open-source tool and enables the frontend to respond meaningfully to any failure without pattern-matching on error messages. These two choices together — database-resident logic and typed error contracts — give Mathesar a runtime behavior more akin to a database client library than a conventional web application.

Self-Hosting

Mathesar is released under the GNU General Public License v3.0 (GPLv3), a strong copyleft license. For self-hosters, this means you can run the software freely for any purpose, modify the source, and redistribute it, but any distribution of modified versions must also be released under GPLv3. For most internal deployments — running Mathesar as a private tool within your organization — the copyleft conditions do not apply, since you are not distributing the software. Organizations building commercial products on top of Mathesar and distributing them to third parties would need to comply with GPLv3’s share-alike requirements or negotiate a separate license arrangement.

Running Mathesar yourself requires a PostgreSQL instance (version 13 or newer is recommended), a server capable of running Docker, and some familiarity with environment-variable-based configuration for secrets, database credentials, and optional SSO. The installation ships as a Docker Compose stack with Caddy for TLS termination, which is relatively approachable for teams already running containerized workloads. You are responsible for database backups, Postgres version upgrades, container updates, and monitoring. When a new Mathesar version is released, the update process involves pulling the new Docker image and running any migrations — the app surfaces available updates in the admin UI to simplify awareness, but the execution is manual.

Mathesar Cloud (mathesar.cloud) is a hosted alternative currently in early beta with a free plan, offered by the Mathesar Foundation. Compared to self-hosting, the cloud option removes infrastructure burden, provides managed updates, and offers a path to community support from the team. The self-hosted version is identical in features — there is no paywalled enterprise tier or feature gating — so the trade-off is entirely operational: convenience and reduced maintenance overhead with the cloud option versus complete data sovereignty and infrastructure control with self-hosting.