While SQLAlchemy can be used in many ways, it's continuing API and usage evolution is geared towards an idiomatic style of application design, which may be referred to as the *foundational* application style. In this style, the application is constructed in two major parts - the first, is the so-called "foundation" which defines patterns and conventions to be used throughout the application, such as base classes, common types and schema elements, and other patterns that may be repeated. The goal of the foundation is to provide as many application details as possible so that they don't find themselves within model or use case logic. The second part of the application is essentially the models and use cases themselves; this part builds upon, and indeed drives the structure and featureset of, the foundation. The goal in this area is for models and use cases to be laid out in as declarative and non-repetitive way as possible. This structure allows new use cases to be added very quickly and allows the overall direction and implementation mechanisms of the application to turn on a dime, with minimal impact on models and use cases as they continue to grow in scope and number. This approach is in contrast to the style proposed by many frameworks in the Python, Ruby and PHP worlds, which seeks to eliminate to as much a degree as possible the need for custom conventions, instead providing an ever broadening set of "out-of-the-box" conventions and helpers seeking to accommodate any possible scenario. While this approach has the advantage of fast ramp up times and early prototyping success, as time passes and use case complexity grows, the mismatch between pre-fab convention and application can degrade quality and maintainability. SQLAlchemy is for applications that are in it for the long haul - instead of being geared towards the ecommerce application you wrote on the plane in 30 minutes, it's geared towards the ecommerce application that sold you the plane tickets. This talk will illustrate a simple Pyramid web application which highlights a variety of conventional patterns that I've been talking about for quite some time, including typing conventions using built-in and custom types, schema naming conventions using events, production of specific SQL expressions using custom SQL constructs, using helper functions and declarative mixins to produce succinct model declarations, simple session setup/teardown patterns, simple unit tests and transaction-enabled integration tests, Alembic migration configuration, and possibly other features.