Biscuit Documentation
Welcome to the official documentation for Biscuit.
Contents:
- Installation Guide
- Quick Start Tutorial
- Step 1: Create Sample Data
- Step 2: Measure Baseline Performance
- Step 3: Create Biscuit Index
- Step 4: Run Optimized Queries
- Step 5: Try Different Pattern Types
- Step 6: Multi-Column Indexes
- Step 7: Aggregate Queries (Special Optimization)
- Step 8: Monitor Index Statistics
- Step 9: Test CRUD Operations
- Best Practices
- Next Steps
- Common Questions
- API Reference
- Biscuit Index Architecture
- Pattern Syntax Guide
- Multi-Column Indexes
- Biscuit Performance Benchmark — Fallback Bitmaps
- Executive Summary
- Introduction
- Methodology
- Test Environment
- Query Coverage Analysis
- Performance Results
- Statistical Analysis
- Statistical Analysis
- Pattern-Specific Performance
- Correctness Verification
- Index Usage Analysis
- Real-World Scenarios
- Trade-off Analysis
- Limitations and Future Work
- Conclusions
- Statistical Methods
- Biscuit Performance Benchmark — Roaring Bitmaps
- Executive Summary
- Introduction
- Methodology
- Test Environment
- Query Coverage Analysis
- Performance Results
- Statistical Analysis
- Pattern-Specific Performance
- Correctness Verification
- Index Usage Analysis
- Roaring Bitmap Optimization Impact
- Real-World Scenarios
- Trade-off Analysis
- Limitations and Future Work
- Conclusions
- Statistical Methods
- Appendix: Verification Checklist
- Benchmark Environment
- Performance Tuning Guide
- Quick Performance Checklist
- Understanding Biscuit Performance
- PostgreSQL Configuration
- Index Design Optimization
- Query Optimization
- Maintenance and Monitoring
- Hardware Considerations
- Benchmarking Your Setup
- Troubleshooting Performance Issues
- Advanced Tuning
- Performance Monitoring Dashboard
- Next Steps
- Tribute to Trigrams and Trees
- Frequently Asked Questions
Biscuit Index for PostgreSQL
High-Performance Pattern Matching Index for LIKE Queries
What is Biscuit?
Biscuit is a specialized PostgreSQL index access method designed to dramatically accelerate LIKE pattern matching queries. Unlike traditional B-tree or GIN indexes, Biscuit uses bitmap-based character indexing to provide near-instantaneous pattern matching across single or multiple columns.
Key Features
Blazing Fast: Optimized for complex
LIKEpatterns including%,_, prefixes, suffixes, and substringsMulti-Column Support: Query across multiple columns simultaneously with intelligent predicate reordering
Aggregate Optimization: Special optimizations for
COUNT(*)andEXISTSqueriesFull CRUD Support: INSERT, UPDATE, DELETE operations with automatic index maintenance
Crash-Safe and Replicated: WAL-logged storage, point-in-time recovery, and physical streaming replication
Smart Query Planning: Automatic reordering of predicates based on selectivity analysis
Memory Efficient: Uses Roaring Bitmaps for compact in-memory representation
Biscuit suits read-mostly, analytical workloads: load data, build the index, then query. Writes against a live index generate considerably more WAL than the heap writes alone, and each backend holds its own cached copy of the index, so plan for connection-pool size. See Performance Tuning.
What’s New — 3.0.0
Durability
WAL-logged, crash-safe storage. All index state lives in the index relation’s own pages and is WAL-logged, replacing the earlier external-file snapshot mechanism. The index takes part in crash recovery, point-in-time recovery and physical streaming replication, including index scans served from a hot standby.
Cross-backend cache coherency. Cached copies are validated against the metapage generation and reloaded when stale, so a backend reliably observes other backends’ committed writes through the index.
Query Execution
Candidate-mask threading across scan keys. Conjunctive queries evaluate the most selective key first and restrict later keys to the surviving rows, rather than evaluating each key independently.
Length-predicate support. Patterns made up only of
_wildcards are recognised as length predicates and answered directly from the length bitmaps.Rewritten cost model. Costs derive from pattern shape, column statistics and relation size, so the planner can weigh Biscuit against
pg_trgmand a sequential scan.
Index Definition
biscuit_like_ops/biscuit_ilike_opsoperator classes, for columns that need only one case mode, avoiding the build and maintenance cost of the structure set they will never be queried with.
Upgrading: this is a breaking on-disk format change. Indexes built under 2.x must be
REINDEXed; there is no automatic migration.
Quick Start
-- Install the extension
CREATE EXTENSION biscuit;
-- Create a Biscuit index
CREATE INDEX idx_products_name ON products
USING biscuit (name);
-- Query using LIKE patterns
SELECT * FROM products
WHERE name LIKE '%laptop%';
Documentation Structure
Installation Guide - Get started with Biscuit
Quick Start Tutorial - Your first Biscuit index in 5 minutes
Pattern Syntax - Understanding LIKE pattern matching
Multi-Column Indexes - Advanced multi-column queries
Performance Tuning - Optimize your queries
API Reference - Complete function reference
Benchmarks - Benchmarks and other statistics
FAQ - Common questions and troubleshooting
When to Use Biscuit
Perfect For:
Text search with wildcards (
%product%,item_%)Email/domain filtering (
%@company.com)Prefix/suffix matching (
admin%,%_test)Multi-column pattern queries
High-cardinality string columns
Frequent
LIKE/ILIKEqueries in analytics
Not Ideal For:
Full-text search (use
tsvectorinstead)Exact equality matches (B-tree is sufficient)
Low-selectivity patterns (single
%)Tables under continuous write load, or deployments with large connection pools
System Requirements
PostgreSQL 16 or higher
Linux, macOS, or Windows
Recommended: CRoaring library for enhanced performance
License
Biscuit is open-source software released under the PostgreSQL License.
Support
Issues: GitHub Issues
Discussions: GitHub Discussions
Email: sivaprasad.off@gmail.com
Ready to accelerate your pattern matching queries?