能否在AWS S3托管SQLite数据库，通过Lambda+API Gateway供低流量网站使用？

可以在S3托管SQLite数据库文件并通过Lambda交互，但这种方案仅适合极低流量、并发量几乎为0的场景，存在诸多关键限制，先给你拆解清楚：

一、实现方式 #

核心逻辑是将S3上的SQLite文件同步到Lambda临时存储进行读写，操作完成后再回传S3：

1. Lambda启动时，把S3中的SQLite文件下载到/tmp目录（Lambda唯一可写的临时存储）
2. 对本地临时文件执行SQL读写操作
3. 操作完成后，将更新后的文件上传回S3覆盖原文件

以下是Python实现的极简示例：

import sqlite3
import boto3
import os

S3_BUCKET = "your-bucket-name"
DB_KEY = "app-database.sqlite"
LOCAL_DB_PATH = "/tmp/app-database.sqlite"

s3 = boto3.client('s3')

def lambda_handler(event, context):
    # 从S3拉取数据库到本地
    s3.download_file(S3_BUCKET, DB_KEY, LOCAL_DB_PATH)
    
    # 连接SQLite并执行操作
    conn = sqlite3.connect(LOCAL_DB_PATH)
    cursor = conn.cursor()
    
    # 示例：查询数据
    cursor.execute("SELECT id, name FROM users LIMIT 10")
    results = cursor.fetchall()
    
    # 示例：写入数据
    cursor.execute("INSERT INTO users (name, email) VALUES (?, ?)", ("Bob", "bob@example.com"))
    conn.commit()
    
    # 关闭连接并回传更新后的文件到S3
    conn.close()
    s3.upload_file(LOCAL_DB_PATH, S3_BUCKET, DB_KEY)
    
    return {"statusCode": 200, "body": str(results)}

二、不可忽视的限制 #

• 并发冲突：S3不支持文件的原子读写，如果多个Lambda实例同时操作，会出现文件覆盖、数据损坏的问题——这是最致命的缺陷，几乎排除了任何有并发需求的场景。
• 性能损耗：Lambda冷启动时必须下载整个数据库文件，文件越大启动越慢；即使热启动，临时文件也可能因实例回收被清空，需要重新下载。
• 存储上限：Lambda的/tmp目录最大仅10GB，SQLite数据库文件不能超过这个大小。
• 事务可靠性：如果Lambda执行中断（比如超时、内存溢出），本地更新的内容可能无法同步回S3，导致数据丢失。

三、更适合的无服务器关系型数据库替代方案 #

既然目标是构建可靠的端到端无服务器应用，优先选择专门的无服务器关系型数据库：

• Amazon Aurora Serverless v2：兼容MySQL/PostgreSQL，自动按流量缩放，按实际使用量计费，低流量场景成本极低，无需管理服务器。
• Amazon RDS Serverless：支持MySQL、PostgreSQL等主流引擎，可自动启停，适合间歇性流量的应用。
• PlanetScale：基于MySQL的无服务器数据库，自带分支功能，适合需要版本控制的开发场景。

内容的提问来源于stack exchange，提问作者David Alsh