Can I use either for full-text search?

Both can, but they approach it differently. Elasticsearch's search tool runs the full Query DSL natively, with analyzers, relevance scoring, highlighting, and explain; it is purpose-built for full-text search at scale. Supabase's execute_sql tool can issue Postgres full-text search queries (tsvector/tsquery), but full-text search is not a dedicated tool and requires knowing the right SQL. For a search-first use case on a large corpus, Elasticsearch is the more natural fit.

Which offers a hosted remote endpoint?

Both do. Supabase offers a hosted remote MCP endpoint at https://mcp.supabase.com/mcp with OAuth login. The Elasticsearch MCP server can run as a self-hosted streamable-HTTP service, but Elastic does not provide a hosted MCP endpoint in the same way; you point the server at your own Elastic Cloud or self-managed cluster URL via ES_URL.

Supabase vs Elasticsearch

Supabase MCP and Elasticsearch MCP both connect an agent to a data store, but the underlying systems are fundamentally different. Supabase is a Postgres-based backend-as-a-service: its server exposes tools to execute raw SQL (execute_sql), inspect tables, extensions, and migrations (list_tables, list_extensions, list_migrations), apply schema migrations (apply_migration), pull project logs and advisors (get_logs, get_advisors), generate TypeScript types (generate_typescript_types), manage edge functions (list_edge_functions, deploy_edge_function), create and merge development branches (create_branch, merge_branch, rebase_branch), manage storage buckets, and handle project-level operations like create_project, pause_project, and restore_project. Elasticsearch MCP, from Elastic, connects to a search and analytics cluster and offers five tools: list_indices, get_mappings, search (with full Query DSL, highlighting, and explain), esql (Elastic's piped query language for aggregations), and get_shards. The choice is shaped by what the data store is: a relational Postgres database with a platform around it, or an Elasticsearch cluster used for full-text search and analytics over your own indices.

How they compare

Dimension	Supabase	Elasticsearch
Underlying system	Postgres via Supabase's hosted platform. The agent operates on relational tables with SQL, with surrounding platform tools for migrations, branches, edge functions, logs, and storage.	Elasticsearch cluster (Elastic Cloud or self-managed). The agent operates on indices with the Elasticsearch Query DSL and ES\|QL, a piped aggregation language. No relational model.
Query surface	execute_sql runs any SQL query against the database (read-only when launched with --read-only). list_tables and list_extensions give the agent schema context before it writes queries.	search executes Elasticsearch Query DSL with highlighting, profiling, and explain; esql runs piped aggregations and analytics. get_mappings provides field-level schema context for the targeted index.
Platform and lifecycle tools	Thirty tools beyond SQL: create, pause, and restore projects; apply and list migrations; create, merge, reset, and rebase development branches; deploy edge functions; list storage buckets; get advisors and logs; generate TypeScript types; search documentation.	Five tools focused on read and analytics: list_indices, get_mappings, search, esql, and get_shards. No write tools, no lifecycle management, no branch or migration surface.
Write capabilities	apply_migration runs DDL against the database; execute_sql can run DML in read-write mode. deploy_edge_function deploys serverless functions; update_storage_config adjusts storage settings.	No write tools exposed. The server is designed for querying, inspecting mappings, and running analytics against an existing cluster, not for indexing documents or managing cluster settings through the MCP surface.
Best-fit task	Working with a Supabase project end-to-end: exploring schema, running SQL in read-only or read-write mode, applying migrations, debugging with logs and advisors, managing edge functions, and branching for safe schema iteration.	Search and analytics over existing Elasticsearch indices: translating natural-language questions into Query DSL searches, running ES\|QL aggregations, inspecting index mappings and shard layout.

Verdict

Choose based on your data store, not your use case. If your application runs on Supabase or Postgres, the Supabase MCP server gives you SQL, migrations, logs, advisors, edge functions, branching, and storage in one package, with a read-only flag for safe production access. If your data lives in Elasticsearch indices, the Elasticsearch MCP server translates queries into the Query DSL and ES|QL, inspects mappings and shard distribution, and returns search results with highlighting and profiling. There is limited overlap: Supabase is a full Postgres BaaS with lifecycle tools; Elasticsearch is a search and analytics engine over your own indexed documents. Pick the one that matches where your data actually lives.

FAQ

Can I use either for full-text search?: Both can, but they approach it differently. Elasticsearch's search tool runs the full Query DSL natively, with analyzers, relevance scoring, highlighting, and explain; it is purpose-built for full-text search at scale. Supabase's execute_sql tool can issue Postgres full-text search queries (tsvector/tsquery), but full-text search is not a dedicated tool and requires knowing the right SQL. For a search-first use case on a large corpus, Elasticsearch is the more natural fit.
Which offers a hosted remote endpoint?: Both do. Supabase offers a hosted remote MCP endpoint at https://mcp.supabase.com/mcp with OAuth login. The Elasticsearch MCP server can run as a self-hosted streamable-HTTP service, but Elastic does not provide a hosted MCP endpoint in the same way; you point the server at your own Elastic Cloud or self-managed cluster URL via ES_URL.