Server vs Client Strategies

Ada supports two filtering strategies via the strategy option in useDataTable:

Server Strategy

const { table, filters, actions } = useDataTable({
  data,
  columns,
  columnsConfig,
  strategy: "server",
  adapter,
  pageCount,
});

In server mode:

• Filtering, sorting, and pagination are handled by your server/database
• URL state is managed by a SearchStateAdapter (nuqs or TanStack Router)
• pageCount must be provided — the server tells the table how many pages exist
• data is the current page of results from your server query
• TanStack Table runs with manualFiltering, manualPagination, and manualSorting enabled

When to use server mode

• Large datasets (hundreds/thousands of rows)
• Data that needs to be filtered at the database level
• When you want shareable/bookmarkable filtered URLs
• Production applications with real databases

Server-side data flow

1. User interacts with filter UI
2. Adapter writes new filter state to the URL
3. Server component re-renders, parses search params
4. ORM filter builder converts filters to a database query
5. Server fetches filtered data and passes it to the client component
6. Table renders the new data

Client Strategy

const { table, filters, actions } = useDataTable({
  data,
  columns,
  columnsConfig,
  strategy: "client",
});

In client mode:

• All data is passed to the table upfront
• TanStack Table handles filtering, sorting, and pagination internally
• No adapter or pageCount needed
• Faceted values are computed automatically from the data

When to use client mode

• Small datasets (under ~500 rows)
• Prototyping or demos
• Static data that doesn't change
• When you don't need URL persistence

Mixing strategies

You can use client mode with a search state adapter if you want URL persistence without server-side filtering:

const { table, filters, actions } = useDataTable({
  data: allData,
  columns,
  columnsConfig,
  strategy: "client",
  adapter, // URL state still works
});

Comparison