While database management systems (DBMSs) are highly optimized, interactions across the boundary between the programming language (PL) and the DBMS are costly, even for in-process embedded DBMSs. In this paper, we show that programs that interact with the popular embedded DBMS SQLite can be significantly optimized - by a factor of 3.4 in our benchmarks - by inlining across the PL DBMS boundary. We achieved this speed-up by replacing parts of SQLite's C interpreter with RPython code and composing the resulting meta-tracing virtual machine (VM) - called SQPyte - with the PyPy VM. SQPyte does not compromise stand-alone SQL performance and is 2.2 faster than SQLite on the widely used TPC-H benchmark suite.
@cite_22: The integration of database and programming languages is dif- ficult due to the dierent data models and type systems prevalent in each field. We present a solution where the developer may express queries en- compassing program and database data. The notation used for queries is based on comprehensions, a declarative style that does not impose any specific execution strategy. In our approach, the type safety of language- integrated queries is analyzed at compile-time, followed by a translation that optimizes for database evaluation. We show the translation total and semantics preserving, and introduce a language-independent classifi- cation. According to this classification, our approach compares favorably with Microsoft's LINQ, today's best-known representative. We provide an implementation in terms of Scala compiler plugins, accepting two nota- tions for queries: LINQ and the native Scala syntax for comprehensions. The prototype relies on Ferry, a query language that already supports comprehensions yet targets SQL:1999. The reported techniques pave the way for further progress in bridging the programming and the database worlds.
@cite_8: We demonstrate SWITCH, a deep embedding of relational queries into Ruby and Ruby on Rails. With SWITCH, there is no syntactic or stylistic difference between Ruby programs that operate over in-memory array objects or database-resident tables, even if these programs rely on array order or nesting. SWITCH's built-in compiler and SQL code generator guarantee to emit few queries, addressing long-standing performance problems that trace back to Rails' Active Record database binding. "Looks likes Ruby, but performs like handcrafted SQL, " is the ideal that drives the research and development effort behind SWITCH.
@cite_6: Relational database management systems can be used as a coprocessor for general-purpose programming languages, especially for those program fragments that carry out data-intensive and data-parallel computations. In this paper we present a Haskell library for databasesupported program execution. Data-intensive and data-parallel computations are expressed using familiar combinators from the standard list prelude and are entirely executed on the database coprocessor. Programming with the expressive list comprehension notation is also supported. The library, in addition to queries of basic types, supports computations over arbitrarily nested tuples and lists. The implementation avoids unnecessary data transfer and context switching between the database coprocessor and the programming language runtime by ensuring that the number of generated relational queries is only determined by the program fragment's type and not by the database size.
@cite_19: 
@cite_5: We demonstrate an efficient LINQ to SQL provider and its significant impact on the runtime performance of LINQ programs that process large data volumes. This alternative provider is based on Ferry, compilation technology that lets relational database systems participate in the evaluation of first-order functional programs over nested, ordered data structures. The Ferry-based provider seamlessly hooks into the .NET LINQ framework and generates SQL code that strictly adheres to the semantics of the LINQ data model. Ferry comes with strong code size guarantees and complete support for the LINQ Standard Query Operator family, enabling a truly interactive and compelling LINQ demonstration. A variety of inspection holes may be opened to learn about the internals of the Ferry-based LINQ to SQL provider.
@cite_19 created the Ferry glue language which serves as an intermediate language to translate subsets of other languages to SQL. That is various front-end languages can translate to that intermediate language, which is then lowered into SQL code. The goal is to reduce the impedance mismatch between languages and database when programming and to improve the efficiency of the interaction. Ferry influenced several works in other languages: @cite_22 developed a Scala plugin that enables programmers to translate Scala-level constructs to Ferry; @cite_8 introduced Switch which uses Ferry-like translation principles to allow seamless integration of Ruby and Ruby on Rails with the DBMS; @cite_6 designed and implemented a Haskell library for database-supported program execution; and @cite_5 created a Ferry-based LINQ-to-SQL provider. Since one of the main goals of Ferry is to reduce the number of times the PL DBMS boundary is crossed, the approach is complementary to the SQPyte approach of reducing the cost of the boundary crossings.