Project Roadmap
Relevant source files
The following files were used as context for generating this wiki page:
The Project Roadmap for Better Tables outlines the strategic evolution of the library, focusing on achieving high developer experience (DX) and robust technical capabilities for large-scale data table management. The roadmap is structured around the major 0.6.0 release, which serves as a coordinated breaking upgrade to establish a new flagship API surface including betterTables() and defineTable().
Sources: plans/README.md:12-25, plans/039-documentation-truth.md:19-24
Current Development Status (2026-07-22)
The project has reached a state where version 0.6 is considered shippable, with primary feature waves A through D merged into the main branch. The current focus has shifted toward adapter expansion and performance optimization.
Completed Milestone Waves
| Wave | Description | Key Outcomes |
|---|---|---|
| A: Pre-0.6 | Core logic and infra | Verification infra, refetch loop fixes, date formatting, path-typed columns, and typed writes. |
| B: Quality | Robustness and docs | CLI bundling, documentation overhaul, integration harnesses, and Drizzle decomposition. |
| C: Features | Advanced Capabilities | Inline editing, schema-driven auto columns, plugins, and export UI. |
| D: Hygiene | Structural integrity | Deterministic typechecking, contract cleanup, and UI modules extraction. |
Sources: plans/README.md:27-46, plans/060-derived-aggregate-columns.md:Status
Strategic Roadmap Objectives
1. Adapter Expansion (Wave E)
A major priority is reaching full feature parity across different ORMs and query builders. This is driven by a shared conformance suite to ensure consistency.
- Prisma Adapter (Full Parity): Implementation of a comprehensive Prisma adapter covering reads, facets, schema introspection, writes, and aggregates.
- Kysely Adapter: Development of a SQL-native Kysely adapter to support SQL composition and aggregate parity.
Sources: plans/README.md:55-66, plans/011-table-definition-dx-design.md:129-135
2. Performance and Scalability (Wave F)
To support "Big Board" scenarios (10k+ rows), the project is implementing a dedicated performance test harness.
- Latency Baselines: Establishing Playwright latency baselines.
- Growth-Ratio Gates: Implementing gates to prevent query count inflation and interaction lag.
- Benchmarking: Utilizing Mitata for trend benchmarking.
Sources: plans/README.md:68-75, plans/029-marketing-showcase-dogfood.md:73-77
3. Advanced Filtering and Aggregates
The roadmap includes evolving the filtering system from flat structures to complex trees and supporting server-derived data.
- Visual Filter Builder (Plan 048): A visual nested AND/OR filter builder to replace or augment the existing flat filter bar.
- Derived Aggregates: Expanding
t.countandt.aggregatesupport across all adapters, allowing for server-side derived columns that remain filterable and sortable.
Sources: plans/README.md:51-53, plans/060-derived-aggregate-columns.md:53-62
Feature Lifecycle Flow
The following diagram illustrates the lifecycle of a feature from design to release within the Better Tables ecosystem.
This diagram shows the progression from technical design and type-level spikes to implementation, dogfooding, and final release.
Sources: plans/011-table-definition-dx-design.md:36-40, plans/029-marketing-showcase-dogfood.md:20-25, plans/README.md:78-83
Deferred and Planned Backlog
Several items have been explicitly deferred to post-0.6.0 development to maintain focus on core stability.
- Global Search: Implementing global search as "filter sugar" over searchable columns (Plan 058).
- UI Components: Column resizing and row expansion (reserved in core but unimplemented in UI).
- Realtime UI: A potential future module for Drizzle subscriptions.
- Additional Adapters: Post-1.0 exploration of Supabase/PostgREST and MongoDB.
- UI Distribution: Maintaining the
@better-tables/uipackage as a private CLI-copy distribution rather than a public npm package for the immediate future.
Sources: plans/README.md:103-120, plans/009-dx-hygiene-sweep.md:162-170
Implementation Policies
The project adheres to strict release and DX policies to ensure long-term maintainability:
- Breaking Changes: The 0.6.0 release is a "coordinated breaking upgrade." No parallel legacy methods or compatibility shims are maintained; the old API surface is removed outright in favor of the flagship API.
- Single Source of Truth: Table definitions should be defined once via
defineTable, which then drives column rendering, filtering, and database query generation. - Zero-Fabrication Docs: Technical documentation must be derived solely from the implementation to prevent drift between code and manuals.
Sources: plans/README.md:14-25, plans/039-documentation-truth.md:27-38, plans/011-table-definition-dx-design.md:300-308
Conclusion
The Better Tables roadmap prioritizes a clean, path-typed API and high-performance data handling. By consolidating around the 0.6.0 release and expanding adapter support, the project aims to provide an end-to-end type-safe solution for complex React tables that remains ORM-agnostic.
Sources: plans/README.md:126-128, plans/011-table-definition-dx-design.md:17-20