搜索功能几乎是每个业务系统的标配，方案选型却常常让人纠结。一边是零成本、零部署的SQLite全文检索，另一边是功能强大但按量付费的Algolia云搜索服务。本文以一个内容资讯站的站内搜索需求为例，从多个维度对两者进行实战对比，帮助你在项目初期就做出正确的技术选择。
架构模式差异：嵌入式引擎与托管云服务
SQLite是一个嵌入式的单文件数据库，整个数据库就是一个磁盘文件，应用进程直接读写，没有独立的数据库服务器。它的FTS5模块提供了全文检索能力，索引数据与业务数据存放在同一个文件中，天然支持事务，备份就是复制文件。这种架构意味着零网络开销、零运维成本，特别适合数据量在几十万到百万级、并发读取为主的场景。
Algolia则是典型的SaaS搜索服务，你把数据通过API推送上去，它负责建索引、分片、容灾，前端通过JavaScript客户端直接查询其全球分布的节点。它的核心卖点是毫秒级响应、容错拼写纠错、同义词配置、个性化排序等开箱即用的高级特性，这些在SQLite中都需要自己实现。代价是数据必须出本地、出内网，且按记录数和操作数计费。
从数据主权角度看，SQLite的数据永远在你的服务器上，不涉及第三方传输，这对合规要求严格的行业（医疗、金融）是天然优势。而使用Algolia必须评估数据出境、隐私条款等问题，某些场景下这会直接否决云方案。
全文检索能力实战对比
先看SQLite的FTS5如何建索引。假设我们有一张文章表，需要支持标题和内容的中文与英文混合搜索：
-- 创建FTS5虚拟表，使用unicode61分词器
CREATE VIRTUAL TABLE articles_fts USING fts5(
title,
content,
tokenize = 'unicode61 remove_diacritics 2'
);
-- 数据写入后同步到FTS表
INSERT INTO articles_fts(title, content)
VALUES('SQLite实战教程', '本文介绍FTS5全文检索的使用方法');
-- 前缀查询与布尔组合
SELECT * FROM articles_fts
WHERE articles_fts MATCH 'SQLite* AND 教程'
ORDER BY rank;FTS5对英文搜索表现不错，支持前缀匹配、BM25排序、高亮函数highlight()。但中文分词是短板：unicode61分词器按空格和标点切词，而中文没有空格，结果是把整段中文当成一个词，只能靠前缀匹配勉强工作。要真正支持中文，需要引入第三方分词器（如simple或jieba分词的SQLite扩展），或者自己预先分好词再写入。
Algolia在这方面的体验则好得多。它内置了对中文、日文、韩文的语言处理，分词、去停用词、复数处理都是自动的。推送数据只需一行代码：
const algoliasearch = require('algoliasearch');
const client = algoliasearch('YOUR_APP_ID', 'YOUR_API_KEY');
const index = client.initIndex('articles');
// 批量保存对象，自动建立倒排索引
index.saveObjects([
{
objectID: '1001',
title: 'SQLite实战教程',
content: '本文介绍FTS5全文检索的使用方法',
category: 'database'
}
], { autoGenerateObjectIDIfNotExist: true });此外Algolia支持typos容忍（用户输入SQLite打成SQlite也能命中）、按点击率自动优化相关性、A/B测试排序规则等。这些能力在SQLite里要么没有，要么需要大量定制开发。如果你的搜索框面向普通C端用户，容错和相关性调优的价值会非常高。
性能与成本：什么规模该用什么方案
性能方面，SQLite在单机、读多写少的场景下极快。FTS5查询百万级文档通常在几毫秒内返回，因为它就是本地磁盘读取加内存计算，没有网络往返。写入时索引同步的开销也可以通过事务批量提交来摊薄。它的瓶颈在于并发写：整个数据库同一时刻只有一个写入者，如果搜索索引需要高频实时更新且并发量大，就需要WAL模式配合合理的写入排队策略。
Algolia的查询延迟一般在10到50毫秒之间（含网络往返），对全球用户都很稳定，且搜索请求与你的应用服务器完全解耦——前端直连，不占用后端资源。但它按「记录数加每月操作数」计费，免费额度只有1万条记录和1万次操作。假设你有10万条文章、日均2万次搜索，月费用会迅速攀升到数百美元级别。相比之下，一台运行SQLite的4核8G云服务器每月只要几十元人民币，还能顺便承载其他业务。
下面的对比表总结了关键差异：
| 维度 | SQLite FTS5 | Algolia |
|---|---|---|
| 部署方式 | 嵌入式，零部署 | 云托管，API接入 |
| 中文支持 | 需第三方分词扩展 | 原生支持 |
| 拼写纠错 | 需自行实现 | 内置容错 |
| 成本 | 几乎为零 | 按记录与操作数计费 |
| 数据主权 | 完全本地 | 数据存于第三方云 |
| 水平扩展 | 单机为主 | 全球CDN节点自动扩展 |
选型建议与混合实践
综合来看，选型可以遵循一个简单的决策路径。如果数据量在百万条以内、用户群体集中在国内单区域、搜索需求以关键词命中为主，且团队有基本的开发能力处理中文分词，SQLite的FTS5是完全够用的，成本优势极其明显。典型的例子是企业内部系统、后台管理工具、中小型内容站的站内搜索。
如果产品面向全球用户、搜索是核心转化路径（如电商、文档站、应用市场），用户输入习惯不可控，需要即时搜索即输即显、个性化排序和完善的统计分析，Algolia的付费是值得的——它省下的是数月的搜索工程开发时间。也可以考虑开源替代品如Meilisearch、Typesense，它们提供了接近Algolia的体验但可自托管，是介于两者之间的折中。
实践中还存在混合方案：用SQLite作为主存储和后台检索，同时把热点数据（如商品、热门文章）增量同步到Algolia供前台即时搜索。同步逻辑可以用应用层双写，或者定时任务基于updated_at字段做增量推送。这样既保留了本地的数据完整性，又获得了云端的高质量搜索体验，代价是多维护一条同步链路，需要处理好一致性和失败重试。
最后提醒一点：搜索选型不是一锤子买卖。初期用SQLite快速上线验证需求，等搜索量级和业务价值被验证后，再平滑迁移到云服务，是风险最低、投入最合理的演进路径。关键是在项目初期就抽象好搜索接口层，让底层引擎可以替换，避免业务代码与某个具体方案深度耦合。