- 31comments
- 73comments
- 6comments
- 362comments
- 3comments
- 162comments
- 36comments
- 5comments
- 518comments
- 6comments
- 92comments
- 2comments
- 120comments
- 166comments
- 7comments
- 299comments
- 16comments
- 356comments
- 23comments
- 22comments
- 46comments
- 87comments
- 4comments
- 44comments
- 5comments
- 6comments
- 5comments
- 119comments
- 275comments
- 115comments
If anyone's curious - https://planetscale.com/docs/postgres/search/get-started#loc...:
They're not providing a local extension with the same performance at the time - it's only offered on their cloud services.
The local version https://github.com/planetscale/lead is mainly just for testing the syntax, it doesn't have the same perf characteristics.
Becoming more the norm for them, Neki is the same.
Immediately rules out ever using them (though I don't currently have any problems that would benefit from that level of scale currently, have in the past though).
Postgres's license allows this but for me (personally) it leaves a bad taste.
I struggle with FTS inside SQL (SQLite and MSSQL). There is often a fairly significant impedance mismatch between the relational concerns and how the documents need to be stored.
I've always preferred to use SQL as the system of record and then build/maintain an external Lucene index. Do we think these integral FTS capabilities are at the point where a hybrid architecture doesn't make sense anymore? How much customization exists in this provider?