SQLite3 / libsqlite3 conflict with GDAL on Lambda (python3.14) Unable to import module 'lambda_function': /var/lang/lib/python3.14/lib-dynload/_sqlite3.cpython-314-x86_64-linux-gnu.so: undefined symbol: sqlite3_deserialize

[nghilethanh09052000]

Summary

Using GDAL (e.g. lambgeo/lambda-gdal layer) together with Python’s sqlite3 on AWS Lambda python3.14 can fail at import time with an undefined symbol on sqlite3_deserialize, even when the handler code looks correct.

Error observed

{
  "errorMessage": "Unable to import module 'lambda_function': /var/lang/lib/python3.14/lib-dynload/_sqlite3.cpython-314-x86_64-linux-gnu.so: undefined symbol: sqlite3_deserialize",
  "errorType": "Runtime.ImportModuleError"
}

Environment

• Lambda runtime: python3.14
• Layer / image: GDAL from ghcr.io/lambgeo/lambda-gdal (or equivalent layer copying /opt/lib from that image)
• App imports both from osgeo import … and import sqlite3

Root cause (short)

1. GDAL is typically built with SQLite support and the layer ships libsqlite3 under /opt/lib (or similar).
2. The managed Lambda Python runtime ships its own libsqlite3 (newer; includes symbols such as sqlite3_deserialize that Python 3.14’s _sqlite3 extension expects).
3. Dynamic linker order: if GDAL’s SQLite is loaded first (e.g. import osgeo before import sqlite3), the process can bind to the older libsqlite3 that lacks sqlite3_deserialize, so importing sqlite3 fails.

This is a native library conflict, not a pure Python bug.